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.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
