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

Charles Swiger cswiger at mac.com
Thu Feb 12 19:47:41 UTC 2015


On Feb 12, 2015, at 1:56 AM, Rob <nomail at example.com> wrote:
> 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.

The grid isn't-- can't be-- locked to atomic clocks during periods of high load.

That's aside from the key point, however.  At what point should you decide
that a potential timesource is not trustworthy?

> A computer clock is driven by a crystal and is not locked to anything
> until you use something like ntpd to lock it.

Yes.  However, before you can lock the local computer clock to a remote timesource,
you need to perform some level of sanity checking.  If you wait 1024 local seconds,
and the remote timesource agrees that ~1024 seconds plus or minus a fraction of
a second have passed, that's fine.

If the remote timesource thinks 1022 or 1026 seconds have passed, however,
one side or the other is exhibiting a ~5 minute per day error.

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

Yes.  A drift of 30 ppm is reasonable and common for commodity hardware.

If you examined a hundred physical machines, I'd be surprised if you found
more than one or two which was worse than 100 ppm.

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

You're describing a TCXO; using a temperature sensor to compensate for thermal
drift would gain perhaps a factor of 5 accuracy.

Regards,
-- 
-Chuck




More information about the questions mailing list