[ntp:questions] Why does ntp keep changing my conf file?
david at ex.djwhome.demon.invalid
Sat Sep 18 09:18:58 UTC 2010
David J Taylor wrote:
> Please check the scales. I very much doubt that ntpdate would achieve
> the 5-10 microsecond accuracy shown by PC Pixie:
The one I looked at was puffin.
> Those PC are all running NTP, not ntpdate. The PCs running Windows do
I presume that this one uses PPS, which isn't meaningful for ntpdate.
The fact remains that offset is not a measure of actual accuracy, except
when ntpd is out of lock. When ntpd is locked, it is a measure of
individual sample errors, for the best recent sample. With ntpd, only a
small part of the offset is applied in each sample period, and the
actual clock error should be roughly an order of magnitude lower than
the RMS offset. With ntpdate, the whole sample error is applied every time.
In fact, if you measure offset with ntpdate and there is a medium term
asymmetry excursion in round trip, nptpdate should show lower offsets
than ntpd, even though the ntpd time is actually a lot more accurate.
So, basically: locked ntpd: RMS offset >> real clock error; ntpdate: RMS
offset ~=/< real clock error. locked ntpd RMS offset ~=/> ntpdate RMS
At a rough guess, I would say that the true error on Pixie approximated
somewhere between the 30 minute and 1 day average, for most of the time.
The exceptions being when ntpd has lost tight lock because of
temperature or network load transients. Even the five minute averages
may have some smoothing in them, if you've used an abnormally fast poll
rate. The danger of using a fast poll rate is that you will actually
lose some of the smoothing that is done by ntpd itself.
Incidentally, if the OP really wants to do comparative timing and
doesn't need the results in real time, the best accuracy will be
achieved by not disciplining the clock at all, but simply logging the
offsets. Because you can see the future, as well as the past, you can
get a better solution for the true error. I believe this is how UTC is
calculated - it is only actually available to full accuracy some time
after the time in question, once the offsets between the national clocks
have been determined.
> not achieve the same accuracy as the one running FreeBSD, of course, but
> with one exception are within about one millisecond, even when running
> over wireless (oh, and except PC Narvik which has just been rebooted)..
More information about the questions