Richard B. Gilbert wrote: > Maarten Wiltink wrote: >> "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> [...] >> >>> 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
