[ntp:questions] Re: NTP precision

David L. Mills mills at udel.edu
Mon Sep 26 16:47:34 UTC 2005


Tom,

No need to speculate. The definitions and error budget with all icky 
details are in the architecture briefing on the NTP project page at 
www.eecis.udel.edu/~mills/ntp.html.

Dave

Tom Smith wrote:

> David Woolley wrote:
> 
>> In article <43373166.90201 at cag.zko.hp.com>,
>> Tom Smith <smith at cag.zko.hp.com> wrote:
>>
>>
>>>    "true" time = systemtime + offset +- (rootdispersion + some other 
>>> error)
>>
>>
>>
>> You also need to add half the root delay.  I believe that the actual
>> figure is calculated by ntpd and used to reject times with too large an
>> error band.
>>
>> Also note that, if things are working properly, the error term will be 
>> larger than the offset.
> 
> 
> The rootdispersion IS half the root delay, as far as I can tell (or 
> includes
> it). The unidentified "some other error" term should, in most cases, be
> small relative to that, I would think, except on a stratum 1 server.
> 
>>
>>
>>> Where "some other error" may or may not be the "jitter" of the root
>>> server (the stratum 0 server/reference clock), and where "true time"
>>> would have to be interpreted as meaning the "true time as perceived
>>
>>
>>
>> I need to delve into the code, in default of an NTP4 specification to
>> be sure, but I think that that is accounted for in the reported root 
>> dispersion.  Generally, this question needs to be answered from
>> the code, rather than black box guesses.
>>
> 
> "That" meaning "jitter", whatever that is, or meaning "some other error"?
> 
>>
>>> by the root server" - probably very small compared to the other
>>> error components. The "offset" is at any time the remaining difference
>>> to be worked off to agree with the consensus time among all the peers,
>>
>>
>>
>> I don't think that is quite true, but I don't have time to check
>> properly.
>>
> 
> If you mean the "offset" reported by "ntpq -c rl 0", I'd be interested to
> know what else it could be. It seems to be the same "offset" reported by
> "ntpdc -c loopinfo".
> 
>>
>>> whereas the "rootdispersion" includes the aggregate contribution of 
>>> delays
>>
>>
>>
>> rootdispersion doesn't include delay.  The primary component is the 
>> assumed
>> worst case error due to clock frequency error integrated over the time
>> between when the ultimate reference clock was read and the time was
>> measured at the leaf node.  On NTP 4, I seem to rememher it includes the
>> jitter and clock resolution errors, but, again one really ought to look
>> at the code.
> 
> 
> Yes, I think Leandro is looking for actual answers rather than repeated
> speculation.
> 
> The consistent reports of "rootdispersion" that I see on a closely 
> synchronized
> system are very close to 1/2 "rootdelay", strongly suggesting to me that it
> does include the delay. I am less sure of whether it also includes 
> anything else.
> For example:
> 
> System 1 (well synchronized and very stable):
> 
> precision=-20, rootdelay=88.780, rootdispersion=43.335, peer=33113,
>                ^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^
> refid=16.105.77.200,
> reftime=c6e26179.31a75cd0  Mon, Sep 26 2005  8:00:57.193, poll=10,
> clock=c6e264b6.7b2f0175  Mon, Sep 26 2005  8:14:46.481, state=4,
> offset=0.211, frequency=-1.514, jitter=0.471, stability=0.001
> ^^^^^^^^^^^^
> 
> System 2 (not as stable or well synchronized):
> 
> precision=-20, rootdelay=99.910, rootdispersion=142.947, peer=35868,
>                ^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^
> refid=207.145.113.115,
> reftime=c6e265c1.6a6c3e6a  Mon, Sep 26 2005  8:19:13.415, poll=8,
> clock=0xc6e26930.b91cfae5, state=4, offset=-46.642, frequency=42.791,
>                                     ^^^^^^^^^^^^^^
> jitter=20.006, noise=121.002, stability=0.052




More information about the questions mailing list