On 2015-02-11, Charles Swiger <cswi...@mac.com> wrote: > On Feb 11, 2015, at 7:23 AM, Rob <nom...@example.com> wrote: >> But I see it has also been explained elsewhere in the thread: ntpd has >> a maximum on the momentary drift of 500ppm, no matter if it is static >> or dynamic or the sum of two. I think that is not warranted. > > Do you believe that a clock which loses or gains over a minute per day > should be assumed to be trustworthy? > > Even a ~$10 wall clock which keeps time only by counting 50 or 60 Hz > waves from the AC line will do better than that. While the power grid > frequency fluctuates in the short term due to load with similar magnitude of > error, the utilities make an effort to correct the time during non-peak > hours with slew rates of 200 - 333 ppm so that AC synchronous clocks > see 86400 seconds per day. > >> There are also other problems with dealing with a variable drift. >> I know from observations that ntpd does not attempt to handle a >> changing drift, it only tries to lock in to the momentary drift and >> when that is changing, it keeps chasing the drift (resulting in an offset). > > chrony supposedly chases the short-term offset more aggressively than > ntpd does, if that's what you prefer. > >> In practice a changing drift is often caused by changing temperature, >> and it would be better to take the first derivative into account as well. > > Certainly it is true that changing temperature will cause a change in crystal > frequency, on the order of ppm's to tens of ppm's per 10 C temperature change. > > But if you're willing to tolerate over 500ppm systemic error, why worry about > a second-order effect in the 10s of ppm's?
A few kernels ago, Linux kernel had problems in calibrating the system clock. It would be off by up to a few 100 PPM, and change from one boot to the next. Ie, this was a consistant drift error. It could be zeroed out using adjtimex, but ntpd is supposed to handle the clock, not demand people fixing things by hand. chrony had no problem. It uses both the frequency and the tick rate adjustments of admtimex. ntpd could have a problem if the linux clock was off by say 400PPM in which case it would leave little headroom for normal operation. Of course the "right" procedure would be to fix the kernel, and that was eventually done, but that eventually was on the order of a year or two. Were all Linux people to give up disciplining their clocks while waiting for the kernel people to get their act together? That hardly seems sensible advice. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
