On Thu, Dec 22, 2011 at 19:11, Paul Sobey <bud...@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. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions