[ntp:questions] NTPD can take 10 hours to achieve stability
cswiger at mac.com
Tue Apr 19 00:30:27 UTC 2011
On Apr 18, 2011, at 5:09 PM, Mike S wrote:
> At 07:25 PM 4/18/2011, Chuck Swiger wrote...
>> On Apr 18, 2011, at 2:54 PM, C BlacK wrote:
>>> Thanks for all the great answers. Now for a harder question, how does the accuracy of the local clock source affect the accuracy of ntpd.
>> Normally, except for stratum-1 NTP servers which are specifically configured to use a high-quality local timesource (ie, GPS, ACTS, WWV, atomic clocks, etc), the local clock isn't used at all.
> Of course it is. Don't confuse the RTC used for power-off timekeeping (or the 127.127.1.0 "local" NTP driver) with the clock source used for timekeeping while operating. NTP doesn't keep time, it keeps the local clock source _in time_. NTP itself doesn't have an accuracy, one is concerned with how accurately it keeps the local clock in sync. If the local clock source is moving around, then NTP is constantly "chasing" it to try and keep it in sync. This has to have an effect on accuracy.
Why would the local clock source "moving around" have any impact on a higher-stratum NTP time source running on some other machine?
Yes, ntpd tries to adjust the kernel clock to stay in sync with the reference timesource, by slewing via adjtime() or stepping via settimeofday() or equivalent, but the accuracy and stability of the reference timesource isn't affected one bit by this. If the local clocksource is relatively stable but inaccurate with a constant offset, running ntpd long enough to create a good estimate of the drift from "real time" will allow ntpd to obtain greater accuracy than the local clock by itself could provide.
More information about the questions