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

On Friday, May 26, 2023 at 4:37:48 PM UTC-4, Edward McGuire wrote:
> 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

The documentation suggests using no higher than maxpoll 10 on systems with a continuous internet connection. The higher polling intervals are meant for systems stuck with intermittent connectivity to keep costs down, such as when using a long-distance dialup time service or a pay-by-the-byte internet connection where a maxpoll of 17 makes sense. That's also a situation where "burst" (not iburst) makes sense as it sends several queries each poll, giving more samples to the clock filter process to hold over ntpd for the day-and-a-half poll 17.

Cheers,
Dave Hart

On Sunday, May 28, 2023 at 12:29:36 PM UTC, Dave Hart wrote:
> The documentation suggests using no higher than maxpoll 10 on
> systems with a continuous internet connection.

> The documentation suggests using no higher than maxpoll 10 on
> systems with a continuous internet connection. The higher polling
> intervals are meant for systems stuck with intermittent
> connectivity to keep costs down, such as when using a
> long-distance dialup time service or a pay-by-the-byte internet
> connection where a maxpoll of 17 makes sense. That's also a
> situation where "burst" (not iburst) makes sense as it sends
> several queries each poll, giving more samples to the clock filter
> process to hold over ntpd for the day-and-a-half poll 17.

Right, you might be paraphrasing the Association Management page.
There is a hard recommendation to not modify the poll interval, but
that is specific to reference clocks. Otherwise, changing poll
limits is only said to be normally unneeded.

It was needed in my case. My configuration could have caused an
unreasonable load on Pool Project if I stuck to normal polling
parameters. They specifically ask that users avoid unreasonable
loads, asking for example that users not add more than four time
servers, nor reduce minpoll. Out of courtesy I made the adjustment
to maxpoll. The change reduced the load on Pool Project servers to
well below what a stock configuration would ever incur.

I'll go further and say that in order to use Pool Project with
confidence and still keep packet rates at or below what they
consider normal, it is necessary to increase maxpoll. With Pool
Project, four time servers is never enough. There are too many
clocks in the pool with really bad offset, and some that violate the
NTP protocol (for example responding with a poll value that is
unequal to the poll value in the query), and worst of all, some are
listed multiple times with different IP addresses, which means one
bad clock can show up as 2 clocks! That breaks the assumptions built
into the clock selection algorithm.

To be protected from 2 faulty clocks, one needs a cluster of at
least 5 of 7 to agree. That is, one needs a minsane of 5, a minclock
of no less than 7, and a maxclock of no less than 8. In my case I
found minclock 11 and maxclock 12 protected the client better from
low precision or low accuracy clocks. And this will create traffic
well beyond what Pool Project wants to see from a client. That is
easily mitigated, but only by increasing maxpoll.

The good news is that I got consistently good clock performance even
with long polling intervals.

Cheers! Edward