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

David Woolley david at djwhome.demon.co.uk
Sun May 8 13:37:57 UTC 2005


In article <d5j5de$k3$1 at dewey.udel.edu>, David L. Mills <mills at udel.edu> wrote:

> By design the two error metrics are root synchroniztion distance 
> (rootdelay / 2 + rootdispersion + jitter) and combined jitter (weighted 

It was my mistake to exclude rootdelay.  For some reason I had thought
that root dispersion included root delay even though peer dispersion 
doesn't.  The parameter I described was rootdelay / 2 + rootdispersion.
I'm on dialup so didn't have a live ntpd to look at typical values.

However, the questioner is using version 3 and, in any case, the last
time I looked, there wasn't a specification for version 4.  I looked
for some sort of RMS error measure in the PDF equivalent of RFC1305
(on paper) but there is certainly no such parameter exposed on the
diagnostic interface and I can find no such internal value either.

If RFC 1305 had had some form of jitter measure, I would have suggested
that might match one possible definition of quality.  (I think it might
be buried in Greek letters and exposed only as part of the overall
rootdispersion in NTP v 3.) (Incidentally, looking at the PDF RFC1305,
appendix F seems to the only part that might benefit from not being
plain text.)

> Please do not use ntpdc as error indicator; it is seriously flawed. Use 

ntpdc was proposed as an easy way of getting the final theta value,
although I also said it almost certainly wasn't the desired parameter.
(Originally I failed to find capital-THETA's calculation, because it is
hidden in an appendix, but it looks as though it is not even indirectly 
exposed in the RFC 1305 diagnostic interface.)

> ntpq and the rv billboard for the rootdelay, rootdispersion and jitter 

For the worst case, I would have thought that the dispersion parameter
required was pkt.rootdispersion, which is only transmitted in the
non-diagnostic packets, as far as I can tell.

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

Only to the extent that there isn't a systematic error (e.g antenna
cable delay for a reference clock or asymmetric transmission rates over
a network).



More information about the questions mailing list