Re: Functional differences when using ntpd as NTP client on NTP-NetBSD 9.3<-->10 ?

[christos%astron.com@localhost (Christos Zoulas)]

In article <3407f89f-6d30-f1a5-d013-77176f249b26%petermann-it.de@localhost>,
Matthias Petermann  <mp%petermann-it.de@localhost> wrote:
>Hello all,
>
>I use ntpd in my Qemu/nvmm VMs as a client to synchronise the (otherwise 
>lagging) clocks. For this purpose, ntpd runs on the host and 
>synchronises on the internet. The ntpd in the VM only knows the host as 
>the only time source and is configured in such a way that it does not 
>give up even in the case of major deviations. This means, I use mostly 
>the defaults with the following adjustments:
>
>```
>$ doas vi /etc/ntp.conf
>
>     tinker panic 0 stepout 30
>
>     #tos minsane 2
>
>     server 192.168.2.10 burst minpoll 4 maxpoll 6 true
>```
>
>This works reliably in the VMs with NetBSD 9.3 as guest. Deviations are 
>regularly compensated for by stepping.
>
>In the VMs with NetBSD 9.99.99 as guest, for some reason no stepping 
>takes place. As a consequence, in a short time deviations of several 
>seconds up to minutes occur.
>
>NetBSD 9.3 contains ntpd 4.2.8p11. In my build of NetBSD 9.99.99, ntpd 
>4.2.8p14 is included, but I have also seen that p15 is now in the tree. 
>Does anyone know if there have been any functional changes between these 
>three versions that could account for this behaviour?
>
>(I am aware that such questions are tricky in the virtualisation 
>context. For what it's worth, the host is running on NetBSD 9.3 with 
>HZ=1000, all VMs are running with HZ=100, and the Qemu processes are set 
>to "near real-time" priority in the host via Schedctl (SCHED_FIFO). 
>Since I have been using this setup with NetBSD 9.3 VMs, I have had no 
>more problems with clock synchronisation. With said NetBSD 9.99.99 VM, 
>all these host-side optimisations don't seem to help. Since the external 
>configuration is the same (same virtual CPU count), I suspect the cause 
>is more on the side of ntpd (or other internal changes that I'm not 
>thinking about at all right now).
>
>As always, I'm grateful for any helpful hints - chrony is compiling in 
>the background and I'll test it tonight as a workaround.

from man ntp.conf:
     The quality and reliability of the suite of associations discovered by
     the manycast client is determined by the NTP mitigation algorithms and
     the minclock and minsane values specified in the tos configuration
     command.  At least minsane candidate servers must be available and the
     mitigation algorithms produce at least minclock survivors in order to
     synchronize the clock.  Byzantine agreement principles require at least
     four candidates in order to correctly discard a single falseticker.  For
     legacy purposes, minsane defaults to 1 and minclock defaults to 3.  For
     manycast service minsane should be explicitly set to 4, assuming at least
     that number of servers are available.

How many clocks are you synchronizing against? Could it be that you
end up with fewer than minclock servers?

christos