During the past week my monitors on several of our telescope control machines started alerting me that their NTP quality was degrading. The unhappy ones were using out of the box configurations of N.pool.centos.pool.ntp.org We surmised that the NTP packets were not reliably traversing the WAN, and we have reconfigured the critical machines to use local servers. Has anyone else seen a degradation of reachability and delay to NTP pool? -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

Yes. Not scientific but I noticed one of my servers drifting in time. Changed to another NTP source seems fine. Regards Paul WB8TSL On Sat, Feb 15, 2020 at 12:09 PM Steve Allen <sla@ucolick.org> wrote: > During the past week my monitors on several of our telescope control > machines started alerting me that their NTP quality was degrading. > The unhappy ones were using out of the box configurations of > N.pool.centos.pool.ntp.org > We surmised that the NTP packets were not reliably traversing the WAN, > and we have reconfigured the critical machines to use local servers. > > Has anyone else seen a degradation of reachability and delay to NTP pool? > > -- > Steve Allen <sla@ucolick.org> WGS-84 (GPS) > UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat > +36.99855 > 1156 High Street Voice: +1 831 459 3046 Lng > -122.06015 > Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. >

NTP pool performance depends on several factors. The primary pool monitor, located in Newark, New Jersey, periodically polls each NTP server. Based on reachability and calculated offset each server is assigned a score. See https://www.ntppool.org/scores/192.36.143.151 for example. If a server's score is too low, it is excluded from DNS responses to N.pool.centos.pool.ntp.org <http://n.pool.centos.pool.ntp.org/> etc. [I can't provided details on the pool's DNS implementation .] Many NTP clients do a DNS lookup only at startup and hence will not learn that a particular server is no longer being advertised by the NTP pool. The "pool" directive supported by some recent NTP clients may help. See https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_pool_usage#pool_directive_vs_server_lines ISPs/IXPs have implementing "NTP filtering" in some (many?) network paths. Filtering consists of rate limits and/or NTP size limits. It seems that the filtering was done in response to DDoS attacks in the mid 2010's that used the mode 7 (private) NTP directive: monlist. Monlist was used in UDP port 123 for amplification attacks. NTP filtering continues to cause problems for the NTP pool administrators and the people who volunteer their servers. The rate limits cause some pool monitor periodic polls to fail which in turn lowers the scores of those NTP servers. The servers may be temporarily dropped from the active pool list. In troubleshooting issues with some European NTP servers I've found that Telia is among those doing the filtering. The forum https://community.ntppool.org/ can be used for pool questions and has some details of the filtering (timeout) problems. NTP filtering can affect clients, of course. 60-80% of the NTP polls from one of my Chicago-based clients towards the NIST Gaithersburg, Md NTP servers fail. CenturyLink is doing in the filtering in this case. The ISP/IXP NTP filtering was implemented as a DDoS defense and viewed by at least some of that community as still being necessary. On Sat, Feb 15, 2020 at 12:01 PM paul swed <paulswedb@gmail.com> wrote: > Yes. Not scientific but I noticed one of my servers drifting in time. > Changed to another NTP source seems fine. > Regards > Paul > WB8TSL > > On Sat, Feb 15, 2020 at 12:09 PM Steve Allen <sla@ucolick.org> wrote: > > > During the past week my monitors on several of our telescope control > > machines started alerting me that their NTP quality was degrading. > > The unhappy ones were using out of the box configurations of > > N.pool.centos.pool.ntp.org > > We surmised that the NTP packets were not reliably traversing the WAN, > > and we have reconfigured the critical machines to use local servers. > > > > Has anyone else seen a degradation of reachability and delay to NTP pool? > > > > -- > > Steve Allen <sla@ucolick.org> WGS-84 > (GPS) > > UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat > > +36.99855 > > 1156 High Street Voice: +1 831 459 3046 Lng > > -122.06015 > > Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts@lists.febo.com > > To unsubscribe, go to > > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. >