[ntp:questions] strange behaviour of ntp peerstats entries.
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
>> paths along the two possible routes shows, even that can, under the right
>> circumstances, be solved.)
>> 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.
More information about the questions