On Sunday, May 21, 2023 at 10:44:27 PM UTC-5, Dave Hart wrote: > I just posted a request for help testing an improvement to ntpd to > automatically refine the set of pool servers being used.
As an aside, in the past I trialed configuring ntpd to do exactly this (automatically kick the worst pool clocks) but without code changes. By way of background, the worst peer is pruned when: * there are more than maxclock associations, and * the peer's unreach is greater than the threshold of 10. And it is possible to tear down candidates by stratum (tos floor N and tos ceiling N) and by distance in seconds (tos maxdist N). By trial and error I found that tos maxdist 0.05 made the trial server server picky enough about pool clocks that it occasionally found fewer than minclock survivors and then invited new volunteers to apply. This created more than maxclock associations and triggered pruning. Periodic invitations might be expected to create an unwanted load on the NPP (Pool Project) servers and the selected peers, but I also increased maxpoll to lower the load to much, much less than a typical NTP server using NPP. The typical server with, say, 7 pool peers and operating at a poll interval of 1024 seconds would transmit a packet on average every 146 seconds. Whereas the trial server tended to collect 24 peers and operate a a pool interval of 32768 seconds, meaning it transmitted a packet on average ever 1365 seconds. This is one tenth of the load put on the NPP by a default-configured NTP server. Summary of parameter changes: pool pool.ntp.org maxpoll 15 tos maxdist 0.05 minsane 5 minclock 11 maxclock 12 -- This is questions@lists.ntp.org Subscribe: questions+subscr...@lists.ntp.org Unsubscribe: questions+unsubscr...@lists.ntp.org
