Stephen, This is a interesting observation but doesn't really address the problem actually.
Since I started this thread two other European pool contributers have said similar things are happening to them. The problem appears to be out of the individual contributor control, it appears to be caused by upstream transit delays to NTP pool monitor HQ. The negative impact to the customer is a valuable pool contributer is removed from the pool. This causes more loads on the remaining pool. In my view the monitor situation needs to be looked at to see if it's still meeting the pool needs. Thank you, R On 21 Feb 2017 18:52, "Steven Sommars" <[email protected]> wrote: The IP hops taken by NTP requests & responses may depend on UDP source and destination port numbers. It isn't unusual to find the delays associated with such paths differing by 10+ msec. Traceroute delays may not match those seen by NTP. NTP delays can be surprisingly long. I commonly see round-trip delays between the US and Japan of over 20 seconds. There are some signs that NTP is being throttled. On Tue, Feb 21, 2017 at 1:59 AM, Ask Bjørn Hansen <[email protected]> wrote: > > > On Feb 20, 2017, at 16:54 , Peter <[email protected]> wrote: > > > > So, it's clearly something between this network and the monitor station. > > What I see on traceroutes is my home connection goes via NTT whereas the > > datacenter goes via a different route. > > You can do traceroutes the other direction with: > > https://trace.ntppool.org/traceroute/82.70.138.66 > https://trace.ntppool.org/traceroute/149.202.2.105 > > (Etc) > > > Ask > _______________________________________________ > pool mailing list > [email protected] > http://lists.ntp.org/listinfo/pool > _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
