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. Regards, -- -Chuck _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
