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

Rob nomail at example.com
Thu Feb 12 09:56:11 UTC 2015


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 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.

That cannot be compared at all!  The grid is locked to atomic clocks, a
clock running on AC will on the average keep very good time.
A computer clock is driven by a crystal and is not locked to anything
until you use something like ntpd to lock it.
The actual frequency of the crystal has some tolerance, and with today's
race to the bottom in prices and quality one really cannot depend on the
accuracy.  For example, when I recently compared some soundcards (similar
issue), a 100ppm error appears to be the norm, even though a crystal
oscillator with some care should be within 10-20ppm.  However, the just
isn't any care anymore.

I personally don't experience problems due to the 500ppm limit right now,
but I would not preclude that it would happen to others, or to me in the
future.

>> 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.

Yes I would prefer that, but chrony does not support local references
so it is useless to me.

>> 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?

Those two things are not related.  I have some systems that I need to
keep within a few microseconds (with PPS) and those do not have that
500ppm error (none of my systems do), they usually within about 30ppm.

However, what I observe is that the plots of the offset show the derivative
of the environment temperature, which unfortunately cannot be controlled
any better.  I am considering to locate the crystal that is responsible
for the timing and see if it could be ovenized or replaced by a more
temperature-stable oscillator.  However, one can argue that it could be
fixed in software as well.  ntpd could sense a changing drift and extrapolate
it, if necessary helped by input from a temperature sensor.



More information about the questions mailing list