[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