[ntp:questions] Accuracy of NTP - Advice Needed

Paul Sobey buddha at the-annexe.net
Fri Dec 23 07:57:19 UTC 2011


On Friday 23 December 2011 03:25:18 Dave Hart wrote:
> On Thu, Dec 22, 2011 at 19:11, Paul Sobey <buddha at the-annexe.net> wrote:
> > - can ntpd's own reported offset (ntpq -p or loopstats) be trusted
> >  (assuming high priority means it gets scheduled as desired)? I've
> > quoted
> >  our apparent numbers at several people and the response is always 'pfft
> >  you can't trust ntpd to know its own offset' - but nobody can ever tell
> >  me why
> 
> This is an interesting issue.  Consider the case where ntpd has just
> started and is reporting 50 msec offset from its source(s).  Using
> ntpd 4.2.7, within the first five (with drift file) or ten (without)
> minutes that offset will be reduced to less than a half millisecond,
> thanks to the new for 4.2.7 initial offset slew, which also avoids
> perturbing the frequency correction during that initial slew.
> 
> During such startup, it is reasonable to assume the best estimate of
> UTC available on that system is the system clock plus the reported
> offset from ntpq.  However, once ntpd has settled down, the best
> estimate of UTC will be the system clock alone, ignoring any offset
> reported by ntpq.  To help understand why, recognize why ntpd has a
> damped response rather than working furiously to eliminate any
> apparent offset as fast as possible:  doing so would be respecting
> noise that gets drowned out by signal through the slower feedback
> loop.
> 
> ntpq -c "rv 0 rootdisp" gives you the estimate of maximum error
> between the local clock and the ultimate source of time (GPS or other
> refclock).  You won't find small-microseconds numbers there.  While
> the average and instant error is likely to be much less, if you're
> careful in talking about ntpd accuracy, you'll want to minimize root
> dispersion.
> 
> A good way to measure ntpd performance is to use a local PPS marked
> noselect as well as a nearby NTP server with PPS.  With peerstats
> enabled, you can consider the PPS offsets logged by the noselect
> refclock a good measurement of the offset of the local clock.

This is great - appreciate you taking the time to write it.

Paul



More information about the questions mailing list