Jan wrote: > If you're giving penalties for being 100 ms off, based on a measurement > with a 500 ms round trip time, you'll end up giving penalties to perfect > servers. And that's exactly what is happening here.
The pool system, while not identical to say how ntpd scores and picks its server when multiple servers are available, is doing a similar job: attempting to pick a server based on its past apparent performance behind the network link. > Theoretically the uncertainty is as big as half the round trip time. > When a server is within that window you have no means to judge its accuracy. We aren't trying to judge accuracy. We're judging sanity and reachability, and similar to ntpd's internal scoring and selection, round trip time comes into play and lowers the score. The scoring is not identical to ntpd's, but the end result is the same: High latency hurts the score a little bit. I know that my two stratum-1 servers are within microseconds of actual time all the time, but I do not expect the pool to be the measure of that! The pool monitoring tools are very useful for watching latency issues before they become serious. I really, really appreciate that instead of plotting the absolute value of the apparent offset, it now plots it as plus or minus. The sign of the offset is, I'm told, irrelevant to the score, but it is HUGELY VALUABLE as a way of making sense of assymetric latencies. And an overall point: aren't the graph date/times in terms of UTC? If so, the asymmetric latency pattern looks EXACTLY like business hours (even excluding lunch hour) somewhere in the US (probably closer to the west coast than the east coast.) Tim. _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
