Does ntp-4.2.8p16 have the voting code in it which
ntp-dev-3792-msm and ntp-dev-3792-msm-v2 has? Dave
Hart recently posted links to tarballs with a request
for feedback?

The fact that p16 hasn't dropped and replaced any
servers, so far, could mean either that ntpd is
"happy" with the its initial server selection or
that the voting code is absent.
--
Roger

On Thu, 08 Jun 2023 15:05:42 +0100, Roger
<invalid@invalid.invalid> wrote:

>Does ntp-4.2.8p16 have the voting code in it which
>ntp-dev-3792-msm and ntp-dev-3792-msm-v2 has? Dave
>Hart recently posted links to tarballs with a request
>for feedback?

Please ignore; I've just spotted that p17 has been released.
--
Roger

On Friday, June 9, 2023 at 7:10:13 AM UTC, Roger wrote:
> On Thu, 08 Jun 2023 15:05:42 +0100, Roger
> <inv...@invalid.invalid> wrote:
>
> >Does ntp-4.2.8p16 have the voting code in it which
> >ntp-dev-3792-msm and ntp-dev-3792-msm-v2 has? Dave
> >Hart recently posted links to tarballs with a request
> >for feedback?
> Please ignore; I've just spotted that p17 has been released.

I'm sorry I didn't notice this earlier. Neither one has the 3792 pool preemption changes. There's still a bit of work needed to prevent continuous turnover in some relatively pathological cases, and likely a bit more work to eventually cycle out even surviving servers very slowly to allow servers that withdraw from a pool to eventually stop receiving queries from updated clients.

Dave Hart

On 2023-06-19 14:50, Dave Hart wrote:
> On Friday, June 9, 2023 at 7:10:13 AM UTC, Roger wrote:
>> On Thu, 08 Jun 2023 15:05:42 +0100, Roger <inv...@invalid.invalid>
>> wrote:
>>
>>> Does ntp-4.2.8p16 have the voting code in it which
>>> ntp-dev-3792-msm and ntp-dev-3792-msm-v2 has? Dave Hart recently
>>> posted links to tarballs with a request for feedback?
>> Please ignore; I've just spotted that p17 has been released.
>
> I'm sorry I didn't notice this earlier. Neither one has the 3792
> pool preemption changes. There's still a bit of work needed to
> prevent continuous turnover in some relatively pathological cases,
> and likely a bit more work to eventually cycle out even surviving
> servers very slowly to allow servers that withdraw from a pool to
> eventually stop receiving queries from updated clients.
>
> Dave Hart
>

For the latter, maybe talk to the pool guys to find or create a DNS way
to check if a previously chosen pool server is still listed?

Such a mechanism could be polled every 8 * maxpoll seconds, so with a
1024s maxpoll that will be about every 2h16m (note: maxpoll, not current
poll). As always DNS, keysetup and other non-sync activities should be
kept out of the timing loops. One scheme could be to check
base32(crc32(IP)).pooldomain, like abc9xyz.1.de.pool.ntp.org will return
the IP if still in the pool for clients asking for 1.de.pool.ntp.org,
client code is needs to check all returned IPs for equality with their
current choice, as hash clashes are explicitly permitted. The crc32
would be calculated over the binary IP (4 or 16 bytes). Base32 is the
RFC4648/RFC3548 Base32 with padding omitted.

Another option would be a KOD message from the retracted server, but
that might not work across NTP protocol implementations and could also
conflict with a desire to keep serving some roaming users or a smaller
part of the pool client population (such as removing
badvendor.pool.ntp.org,, or limiting to payingvendor.pool.ntp.org),
in contrast the above proposal is easily implemented by a parallel
thread or process using a fairly trivial call sequence much easier
than the usual NTP algorithms.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded