[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