[ntp:questions] NTP offset doesn't change.

William Unruh unruh at invalid.ca
Fri Feb 13 00:10:19 UTC 2015


On 2015-02-12, Harlan Stenn <stenn at 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 <cswiger at mac.com> wrote:
>> > On Feb 11, 2015, at 7:23 AM, Rob <nomail at 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 at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
>> 



More information about the questions mailing list