Re: Clock drift and other open issues: Collecting information

I have run the stock ntp.conf for -current (the same system I cross-compiled
with all the gcc patches and did my build with).  The changes I made to
the default ntp.conf file were as I said, I removed the "iburst" from the
pool declaration and I left my "server 192.168.44.1" in the config.

I try to remember to remove any old /var/db/ntp.drift file but forgot.
The one left had a value of 0.000 of all things.  Anyway, running on
the 4000/60 all day it behaved very much as one might expect.

I started here:

$ ntptime

ntp_gettime() returns code 0 (OK)
  time e936ad61.46ec0724  Wed, Dec 27 2023  9:04:17.277, (.277039970),
  maximum error 315266 us, estimated error 14987 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 26759.656 us, frequency 0.879 ppm, interval 1 s,
  maximum error 315266 us, estimated error 14987 us,
  status 0x2001 (PLL,NANO),
  time constant 6, precision 0.001 us, tolerance 496 ppm,

$ ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 2.netbsd.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.122
+firewall.localh 192.168.44.6     2 u   17   64   77    4.896  +48.424  34.862
+2600:1f13:2c1:2 219.119.208.14   2 u   28   64   77  103.997  +52.607  49.533
+vps-5852c97b.vp 141.32.131.246   2 u   33   64   77   60.403  +59.161  33.701
+time3.sigi.net  89.154.213.243   2 u   30   64   37   51.576  +51.522  19.622
*tic.lbl.gov     .GNSS.           1 u   36   64   77   83.268   +4.013  41.549
+108.181.220.94  225.254.30.190   4 u   41   64   77   46.588  +53.320  38.529
+coco.presumed.n 156.145.144.204  3 u   36   64   77   55.928  +57.287  33.991
+sea.mrow.org    .SOCK.           1 u   47   64   77   96.061  +49.135  27.076
+sensei.ruselabs 128.138.140.44   2 u   46   64   77   83.565   +3.899  42.292
+ntp7-2.mattnord 192.126.175.149  3 u   45   64   77   34.295   +5.872  37.352
+ntp.md          .GPPS.           1 u   49   64   77   45.730   +3.838  45.157
+ovh.maxhost.io  135.45.28.167    2 u   46   64   77   98.446   +8.348  34.671

and arrived at this point, this evening:

$ ntptime

ntp_gettime() returns code 0 (OK)
  time e93714e7.a4d6e480  Wed, Dec 27 2023 16:25:59.643, (.643904340),
  maximum error 247133 us, estimated error 1496 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 1614.385 us, frequency 11.938 ppm, interval 1 s,
  maximum error 247133 us, estimated error 1496 us,
  status 0x2001 (PLL,NANO),
  time constant 7, precision 0.001 us, tolerance 496 ppm,

$ ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 2.netbsd.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.122
+firewall.localh 192.168.44.6     2 u   22  128  377    5.268   -0.469   0.885
*time3.sigi.net  89.154.213.243   2 u   25  128  377   48.788   +2.194   1.855
-108.181.220.94  225.254.30.190   4 u   39  128  377   47.613   +4.834   9.248
+ntp7-2.mattnord 225.254.30.190   4 u   83  128  377   35.103   +3.989   0.888
-ntp.md          .GPPS.           1 u  150  256  377   47.419   +1.261   3.208

The estimated clock drift (frequency) slowly climbed to this point, as
it approaches what I saw yesterday, running just two "time servers" and
no "iburst".

It seems like quite a reasonable drift rate to me, and it got here without
a lot of horrible never-ending thrashing like I saw when trying to use
the stock "iburst" rapid convergence tag that does work very well on
"modern" equipment with gigabit NICs and fast networks.