[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:
> 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
> 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.
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.
More information about the questions