[ntp:questions] Why does ntp keep changing my conf file?

[David Woolley]

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:
> 
>  http://www.satsignal.eu/mrtg/pixie_ntp.html

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

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