On 2015-02-12, Harlan Stenn <st...@ntp.org> wrote: > Bill, > > So you believe: > > - the broken linux kernel behavior is an acceptable (or at least > excusable) fact of life,
Of course not. However, it IS a fact of life, and I have to live in the real world. nptd spends many lines of code correcting for rare conditions in the real world. But not this one. > > - that should have been predicted and accommodated by stable-running > software and algorithms that have been around for decades, That the kernel people screwed up was perhaps unpredictable. That clocks could have drift rates substantiallydifferent from 1 sec/sec could have been predicted. > > - 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. All of the above are predicated on you wrong assumption that I thought that the kernel screwup could be predicted. > > And the net effect of the above indicates a shortcoming in the way NTP > was designed, right? The inability to deal with the real world, when that is one of its design goals IS a shortcoming in NTP, yes. > > That's OK, and it's why I don't take your messages very seriously. Of course I cannot make you take anything seriously. I would have thought that designing ntpd to handle the real world would be something you take seriously. And that when you discover a feature of the real world that ntpd does not handle but could, that you would seriously consider changing ntpd so that it does. > > 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