[ntp:questions] Re: HowTo calibrate system clock frequency using NTP
Richard B. Gilbert
rgilbert88 at comcast.net
Thu Feb 2 00:25:50 UTC 2006
Daniel Kabs wrote:
> Hello Professor Mills,
>
> I tried both of your suggestions and the results differ slightly:
>
> Plan A)
>
> After running NTP daemon for two days, the frequency converges to
> 268.3 PPM, i.e. 23.2 seconds per day.
>
>
> Plan B)
>
> Running NTP daemon using "disable ntp", I recorded the offset of the
> associated peer periodically for a couple of hours. A least-squares
> fit gave a slope of 23.7 seconds per day. (At the same time I recorded
> the offset using deprecated ntpdate and got 23.8 seconds per day).
>
> Please see the diagrams on
>
> https://ntp.isc.org/bin/view/Support/HowToCalibrateSystemClockUsingNTPDev
>
>
> I wonder if this difference shows the maximum precision (i.e. 500
> ms/day) I will achieve with these calibration procedures or if I'm
> doing something systematically wrong.
>
>
> Cheers
> Daniel
>
What problem are you trying to solve?
If you want to make a one-time correction to your clock frequency, 500
ms/day may be a reasonable objective. As Terje pointed out, the
frequency varies with temperature and the temperature varies with the
time of day, season of the year, whether the heat is on or off, etc.
The frequency will also change, slowly, as the crystal ages.
Whatever you set the frequency to, today, will probably be not quite
right for tomorrow, next week, etc.
This is why we run ntpd on our computers to synchronize our clocks to an
atomic clock somewhere. The atomic clock is several orders of
magnitude better than the undisciplined local clock and ntpd can
generally hold your local clock within +/- 20 milliseconds of the
correct time using servers on the internet. With a hardware reference
clock (GPS timing receiver) and a judicious choice of hardware and
operating system it is possible to hold the local clock within, perhaps,
+/-50 microseconds of the correct time.
More information about the questions
mailing list