[ntp:questions] strange behaviour of ntp peerstats entries.
Richard B. Gilbert
rgilbert88 at comcast.net
Wed Jan 30 16:22:47 UTC 2008
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.
More information about the questions
mailing list