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

Reply via email to