On Thu, Nov 21, 2024 at 4:56â¯PM Brian Inglis <
Post by b***@systematicsw.ab.caPost by b***@systematicsw.ab.caMaybe add "iburst preempt" options and drop "poll 11" or perhaps change
to
Post by b***@systematicsw.ab.caPost by b***@systematicsw.ab.ca"maxpoll 11" or higher, unless you have very good reasons to require a
longer
Post by b***@systematicsw.ab.caPost by b***@systematicsw.ab.cainterval than the default maximum, instead of adaptive polling based on
the error.
Post by b***@systematicsw.ab.caWell, the documentation (confopt) tells me that the pool command
"mobilizes a preemptable pool client mode association for the
DNS name specified." Why would adding "preempt" change anything?
In fact it won't change anything. The only options propagated from the "
pool" directive in ntp.conf (and thereby set on the prototype pool
association listed with refid POOL in the peers billboard) to the resulting
pool server associations are "iburst" and "noselect". See POOL_FLAG_PMASK
in source code file ntp_proto.c.
The preemptible option is forced on for pool servers, so they are
preemptible with or without that option. However, that option doesn't do
much in 4.2.8 as the code intended to preempt useless servers has an
off-by-one error that's corrected in my test 3792 release, so preemption
only happens in the unusual case where there are more than 2 times as many
pool or manycast client associations as "tos maxclock" which defaults to
10. Arguably this could be fixed in the stable 4.2.8 branch but it would
be a substantial change in behavior without any configuration change that
might break existing setups that depend on the off-by-one error.
As an aside, using "preempt" on a non-pool non-manycastclient association
(basically, configured via "server" or "peer") seems quixotic to me, as it
allows the association to be removed but nothing is done to replace it. I
have a difficult time imagining where that might be useful. It may have
been useful in the pre-2009 implementation of "pool" which I'm having a
hard time remembering because I thought it was primitive and needed
improvement, as it did all its work at startup and never changed the
servers selected once up and running. I re-implemented it to the current
iteration, but didn't catch that the preemption was suffering the
aforementioned off-by-one error, or it wasn't back then.
If you're wondering why I mentioned "manycastclient", it shares much of the
implementation with "pool". They use different approaches to finding
servers, but the rest of the code is common. Both are intended to be
automatic server discovery schemes that discard, or preempt, servers which
haven't been useful for 10 poll intervals so that another server can be
solicited to replace it.
Post by b***@systematicsw.ab.ca$ grep 'pool.*preempt' ~/src/time/ntp/ntp-4.2.8p18/ntpd/complete.conf.in
pool 2.ubuntu.pool.ntp.org. iburst preempt
complete.conf.in is part of the "make check" tests and is not intended to
suggest useful configurations. Rather it's used both to ensure every
keyword in the configuration file parser is covered, and to ensure a
configuration can successfully round-trip through ntpd's reading and
applying the configuration and exporting the configuration via the
--saveconfigquit command-line option added specifically for that developer
test to catch changes which break that functionality. It's no coincidence it
is ordered exactly the same as the output of ntpq's saveconfig command,
which requires authentication and that a directory for such saved
configuration files has been specified in ntp.conf with "saveconfigdir".
Post by b***@systematicsw.ab.ca$ man 5 ntp.conf
...
Configuration Commands
...
*pool* For type s addresses, this command mobilizes a persistent
client mode association with a number of remote servers. In
this mode the local clock can synchronized to the remote server,
but the remote server can never be synchronized to the local
clock.
...
...
*preempt* Says the association can be preempted.
...
This manual page was AutoGenâerated from the ntp.conf option definitions.
4.2.8p18 25 May 2024 ntp.conf(5man)
https://www.ntp.org/documentation/4.2.8-series/confopt/#server-commands
"Server Commands and Options
Last update: March 23, 2023 21:05 UTC (6ad51a76f)
...
Server Commands
...
pool
For type s addresses (only) this command mobilizes a preemptable pool client
mode association for the DNS name specified. "
...
Server Command Options
...
preempt
Specifies the association as preemptable rather than the default persistent.
This option is ignored with the broadcast command and is most useful with the
manycastclient and pool commands."
Despite the timestamps you quoted, the web version is likely newer.
Autogen is run against the documentation source files with every release,
so that timestamp reflects the release date, not the last update of the
documentation source files (.html in this case).
Since the overhaul of the www.ntp.org website a few years back, that
documentation sadly is maintained in two places, and there's no process to
ensure they stay in sync. The web version is considered the more
authoritative source, and is maintained in .md (Markdown) published only
via the converted HTML on the website. It started as a copy of the
documentation from the source tarballs' /html directory, but after
conversion to Markdown and subsequent improvements, those changes have
generally not been made to the HTML version distributed with the source.
I'm partly to blame because I find writing documentation tedious enough
without having to update it in two places, and I've been kept quite busy
with coding work and haven't wanted to take the time to correct
documentation that no longer reflects the reality of the code. In theory
one day I will have time to dedicate to that, but I welcome anyone who
enjoys documentation work or at least really wants accurate NTP
documentation to please volunteer to help out.
Post by b***@systematicsw.ab.caPost by b***@systematicsw.ab.caMy question is why would a preemptable server, acquired using
"pool ...", continue to be polled after it has stopped
responding, i.e., the reach has gone to 0? It is a
misunderstanding on my part or is there an bug in the code?
Or a doc bug?
A doc bug and an off-by-one bug in the preemption logic.
Cheers,
Dave Hart