[ntp:questions] Re: How to get combined clock offset

David Lyons David_Lyons at raytheon.com
Tue May 10 17:56:19 UTC 2005

Our system deploys NTPv3, possibly due to status of NTPv4 Protocol

In my context "Time Quality" is the time offset of the local node's time
relative to the time

When I display the ntpq rv billboard I see, e.g.
... , phase=0.742, ...

Would this be the last offset relative to the reference source?  What are
its units (milliseconds?).

In NTPv3 I don't see any "offset" or "jitter" values.

Dave L.

questions-bounces at lists.ntp.isc.org wrote on 05/07/2005 03:37:13 PM:

> David,
> By design the two error metrics are root synchroniztion distance
> (rootdelay / 2 + rootdispersion + jitter) and combined jitter (weighted
> by synchronization distance). The former is the maximum error, the
> latter the estimated error. There are tricky little details in the error
> budget that have changed over the versions, but the original intent
> Please do not use ntpdc as error indicator; it is seriously flawed. Use
> ntpq and the rv billboard for the rootdelay, rootdispersion and jitter
> displays. Note the jitter display, which includes both peer jitter and
> selection jitter, is probably the best indicator of expected time
> quality. Read this as follows: the best estimate of the server time is
> the offset in the rv display, with jitter as the uncertainty about that
> value.
> That's all that can be said about the statistics. A more thorough
> analysis would have to use the loopstats and compute the distribution
> function, such as displayed in the briefings on the NTP project page.
> Dave
> David Woolley wrote:
> > In article <mailman.78.1115371918.573.questions at lists.ntp.isc.org>,
> > David Lyons <David_Lyons at Raytheon.com> wrote:
> >
> >
> >>We need to get a measurement of "Time Quality" for our node.  We are
> >>NTP Version 3.
> >
> >
> > Why are you interested in quality but using an obsolete version?
> >
> >
> >>It seems that the NTP system state variable "theta", the combined clock
> >>offset, would be the variable we need.
> >
> >
> > Overall theta is offset in loopinfo (ntpdc) and the individual thetas
> > are the offsets in the peers displays.  It's not a quality indicator.
> > If ntpd where confident of the value of theta, it would have corrected
> > the local clock by that amount, so theta would be reduced until it was
> > no longer confident in the value.  In fact, I think that there isn't
> > really an overall theta, but rather theta for the most recently
> > reference clock, at the time it was polled.
> >
> > What would be a good measure depends on what you mean by quality.
> > ntpd's main quality measure is root dispersion, which is the worst case
> > error, assuming that the ultimate reference is a real reference clock
> > not someone's local clock (basically it assumes that all the
> > delay could be in one direction and that the clock has drifted at the
> > maximum reasonable rate since the last measurement).
> >
> >
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions

More information about the questions mailing list