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

David J Taylor david-taylor at blueyonder.co.uk.invalid
Sat Sep 18 13:35:40 UTC 2010


"David Woolley" <david at ex.djwhome.demon.invalid> wrote in message 
news:i72065$4au$1 at news.eternal-september.org...
> 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.

Puffin is a Windows Vista PC, running over a WiFi link, hanging off a 
WRT54GL running DD-WRT.  The reference server Pixie connects directly to 
that same router.  I still doubt that ntpdate would do better.

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

Pixie has a GPS/PPS source, with the usual minpoll 4 and maxpoll 4.

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

That may be right, but how well that would work in the presence of 
arbitrary masking of interrupts and other timekeeping disturbances which 
may occur on a real system, I don't know.

Cheers,
David 




More information about the questions mailing list