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 -- This is [email protected] Subscribe: [email protected] Unsubscribe: [email protected]
