[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