Bill, So you believe:
- the broken linux kernel behavior is an acceptable (or at least excusable) fact of life, - that should have been predicted and accommodated by stable-running software and algorithms that have been around for decades, - where no other kernel has ever misbehaved in this way, - and other projects should deal with that mess; - and chrony, a program with one design goal of closely tracking a master avoids this kernel brokenness. And the net effect of the above indicates a shortcoming in the way NTP was designed, right? That's OK, and it's why I don't take your messages very seriously. H William Unruh writes: > 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 o > f > > 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 cryst > al > > frequency, on the order of ppm's to tens of ppm's per 10 C temperature chan > ge. > > > > But if you're willing to tolerate over 500ppm systemic error, why worry abo > ut > > 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 > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
