[ntp:questions] strange behaviour of ntp peerstats entries.

Brian Utterback brian.utterback at sun.com
Wed Jan 30 17:00:59 UTC 2008


Richard B. Gilbert wrote:
> Maarten Wiltink wrote:
>> "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message
>> news:479F8551.5000505 at comcast.net...
>> [...]
>>
>>> I can imagine an RTT of 60-70ms.  What I have difficulty imagining is
>>> using such a source to synch with.
>>
>>
>> Pfft. Kids these days.
>>
>> (There's nothing wrong with an RTT of 60 to 70 ms per se. For example, if
>> it were always exactly 65 ms, that would probably be an *excellent* time
>> source. The problem is the jitter, and as the example of the four 
>> possible
>> paths along the two possible routes shows, even that can, under the right
>> circumstances, be solved.)
>>
>> Groetjes,
>> Maarten Wiltink
>>
>>
> 
> Well, since the maximum error in transmitting time from server to client 
> is one half the round trip delay, it is usually wise to try to minimize 
> that delay.  A server in Tokyo might have the time correct to within 50 
> nanoseconds but that does me little good in New Jersey!  The network 
> path would be so long and pass through so many routers and switches that 
> by the time it gets to me, the uncertainty will be a substantial 
> fraction of a second.
> 
> Usually, the number of possible paths will be far greater than four!
> 
> The ultimate test is the actual performance under the stated conditions.
> Based on general principles, the stated conditions are NOT where I would 
> look first for best performance.
> 

Which is why NTP prefers the source with the smallest delay. The system
I am using has servers whose delays are 51ms to 94. I can't find any
closer. On my company LAN, the delays range from 16ms to 87ms. The
offsets of all these servers agree to within 9ms. Sure, I am not
going to get sub-millisecond from that, but I think it is probably
more typical than your set-up.

Brian Utterback




More information about the questions mailing list