[ntp:questions] FUD (Was: Re: ntpdate works, but ntpd doesn't (reach = 0))
unruh-spam at physics.ubc.ca
Fri Feb 13 16:42:23 UTC 2009
Steve Kostecke <kostecke at ntp.org> writes:
>On 2009-02-12, Unruh <unruh-spam at physics.ubc.ca> wrote:
>> If only Linux had not screwed up the calibration of the system clock,
>> so that the drift rate varies by up to 50PPM on each reboot. Means it
>> takes about 10 hours for the system to recalibrate and settle down.
>You frequently make this claim without identifying the application or
>defining your criteria for "settled down".
I have stated it in the past but here it is again.
Application-- ntpd 4.2.4p4. "Settle down" means get to within the one
standard deviation of the usual jitter of the system(in my case, a GPS
driven Linux system). The more accurate statement is that the half life is
of the order of 1 hr-- ie, after 1 hr the offset has been reduced by 1/2,
after 2 hrs, by 1/4 etc. The system -- Linux with kernel
188.8.131.52-desktop-2mnb (Mandriva 2008.1) Default timer system--tsc clock
source, resulting in about 20PPM shift in clock drift rate between reboots.
(reboot results in time error after reboot of less than a ms, but rate
error of 20PPM.) In order to correct that rate error, ntp slews the clock
resulting in about 100ms offset error, and it then takes about 10 hr for
the system to get down to the 2-3usec offset it has in long term steady
>In my experience ntpd on Linux is more than close enough after a reboot
>for most applications.
Well, that of course depends on what you mean by "close enough" If you mean
100ms I agree. If you mean usec, I disagree.
>Steve Kostecke <kostecke at ntp.org>
>NTP Public Services Project - http://support.ntp.org/
More information about the questions