In my case at least, it's definitely upstream of the ISP itself and specific (or at least includes) transatlantic connectivity. The reason I say this, is as I've documented. I have my own monitoring between a known good server under my control also in Europe, and the server in my home. The difference is generally consistently <1ms between the two. However against the monitoring station it's generally +/- 500ms (mostly within 100ms) with frequent huge dropouts and score going into minus.
Interestingly most of the traceroutes involved in the Europe problem include NTT. But, there's a report of a server that is good, also traversing NTT. It makes me wonder if NTT have more than one transit tariff, and that our ISPs are taking a cheaper, lower priority tariff, or one that includes some level of throttling/de-prioritization of NTP traffic. I'm somewhat tempted to try to start some AWS/Azure instances in various US zones and testing various test cases of NTP traffic from my home network vs datacenter. But, that's for a day when I have time on my hands. On 23 February 2017 at 09:38, Tim Bray <[email protected]> wrote: > On 23/02/17 00:04, Arnold Schekkerman wrote: > > All you do with multiple monitoring servers is check more routing > options. The only > > logical thing to do is to reject the server from the pool as soon as it > is > > unreachable via at least one route. From our client's perspective this > would make > > the pool more reliable. However, even more servers will see their score > drop... > > > > Please, keep in mind the monitor is NOT about checking if a server knows > the > > correct time. It is about checking if a server (with correct time) is > able to > > *provide* that time to a client connecting to it from just anywhere on > the internet > > using the DNS system. > > > Exactly, this. > > Multiple monitoring should reject more servers. > > Because really if you have a server that is connected to an ISP with > routing problems, then I think that server shouldn't be in the pool. > > > I guess it is hard to accept that your score is low because of your ISP > or even your ISPs upstream connectivity. Even when you know you have > done everything correctly. > > > > A different problem is a good way to investigate these kind of funnies > and try to work out what is going on and what the real problem is. > > > > -- > Tim Bray > [email protected] | +44 7966 479015 | http://www.kooky.org > Huddersfield, UK > _______________________________________________ > pool mailing list > [email protected] > http://lists.ntp.org/listinfo/pool > _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
