[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
Specification.

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

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.

Thanks,
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
remains.
>
> 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
using
> >>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
selected
> > 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
and
> > not someone's local clock (basically it assumes that all the
propagation
> > 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