linux-kernel - Re: Linux 2.6.29-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Feb 2009 12:50:00 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jesper Krogh <jesper@...gh.cc>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>
Subject: Re: Linux 2.6.29-rc6

On Fri, 2009-02-27 at 08:33 +0100, Ingo Molnar wrote:
> * john stultz <johnstul@...ibm.com> wrote:
> 
> > On Thu, 2009-02-26 at 14:40 -0800, Linus Torvalds wrote:
> > > 
> > > On Thu, 26 Feb 2009, john stultz wrote:
> > > > 
> > > > I'll kick up some of my own testing between these two releases to see if
> > > > I can't find something similar.
> > > 
> > > Since the PIT timer read is possibly hw-dependent, it might be that you 
> > > can't necessarily reproduce it on some random hardware.
> > > 
> > > How sensitive is ntpd to (stable) drift? IOW, if we get the calibration 
> > > wrong, the TSC should still hopefully be very _stable_, it's just that the 
> > > initial guesstimate for the frequency is off and ntp would have to correct 
> > > for that.
> >
> > NTP can adjust the clock about +/-500ppm (so a 1000ppm range). 
> > Past that it starts throwing errors.
> 
> Well, it will start throwing errors but still it will correct 
> the clock and find the frequency delta between the host clock 
> and the reference clock just fine, and converge in a couple of 
> hours, correct?

No  NTP spec limits the freq correction to ~+/-500ppm. Once NTPd hits
that 500ppm wall, it will throw an error and stop trying to sync the
clock.

> 500ppm is 0.05% of a frequency drift which is awfully small - 
> thermal effects alone can cause such differences so it should 
> not be anything out of the ordinary for ntpd.

Practically I've not seen boxes that vary that much. I've seen very poor
systems who's crystals are off by ~280ppm, but those don't vary that
much over time much.


> > Part of the issue is that if the drift value changes in 
> > between boots, NTPd can take a while to settle down on the 
> > right freq. I suspect that's whats happening here, and should 
> > the box be left alone for a few hours (maybe overnight) NTPd 
> > will find the new drift correction the issue will go away.
> 
> If the default poll interval of 64 seconds is used then it can 
> take that much time - so i'd sugges to decrease that to below 10 
> seconds.

Indeed. Shortening the maxpoll value in the ntp.conf greatly improves
how fast and how close the client will sync to the server, but take
caution, as that can cause undue load on public time servers.  

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/