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

David L. Mills mills at udel.edu
Sun May 8 15:28:02 UTC 2005


David,

First, rfc1305 and xntpd are completely cold, dead and gone. The rfc1305 
continues as a description of most aspects of NTPv4, but the detailed 
algorithms have evolved as described in the journal articles and white 
papers at the NTP project page linked from www.ntp.org. The NTPv4 spec 
is under way and documented in the briefings at the NTP project page. 
The architecuture briefing lays out the error budget in some detail.

Dave

David Woolley wrote:
> 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