-
Richard Laager authored
This documents everything I've learned about maxclock: - Pool entries count towards maxclock, but not minclock. This is arguably a bug, but it is the current behavior and changing it breaks backwards compatibility to some degree. I posted my experiences here: https://lists.ntpsec.org/pipermail/devel/2019-November/008858.html saying: I have a number of systems with "tos maxclock 11" set explicitly and their steady state is 4 pool entries and 7 actual associations. Hal confirmed here: https://lists.ntpsec.org/pipermail/devel/2019-November/008859.html saying: It uses working slots on the min test but counts pool on the max test. - maxclock should be an odd number. I posted here: https://lists.ntpsec.org/pipermail/devel/2019-November/008856.html saying: http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers says "the general rule is for 2n+1 to protect against 'n' falsetickers". (It goes on to discuss the exception for n=1, which is not relevant here.) If that's true, then it seems like odd numbers of servers are better, all things being equal. - I kept the existing bit about maxclock typically being two greater than minclock, but expanded that to "two or three" to be consistent with the goal of maxclock being an odd number. I also added a note about a typical minclock value being 3. This allows for protecting against one falseticker.
39138c27