Re: Clock drift and other open issues: Collecting information

I have never seen "ntpq -p" output that looked so "fixed" like that.

I was doing testing on a 4000/60 all day yesterday.  This is with
the stock ntp.conf with my firewall added as a server... after hours
of running it still was a mess.

$ ntptime

ntp_gettime() returns code 0 (OK)
  time e935a33a.79c0b998  Tue, Dec 26 2023 14:08:42.475, (.475597712),
  maximum error 294281 us, estimated error 16068 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -105928.185 us, frequency 197.619 ppm, interval 1 s,
  maximum error 294281 us, estimated error 16068 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   60   64  377    5.151  -111.45  52.715
*time3.sigi.net  89.154.213.243   2 u   49   64  377   48.596  -181.34  42.226
#2001:470:b:22d: 192.168.10.254   2 u   54   64  377  114.103  -116.21  52.900
+uschi5-ntp-001. 204.117.185.216  2 u   57   64  377   67.340  -176.04  34.350
+2607:f1c0:1800: 216.239.35.12    2 u   56   64  377   56.987  -177.23  43.548
+159.203.82.102  50.205.57.38     2 u   62   64  377   52.463  -167.51  32.022
#ntp06.cymru.com 172.18.54.10     2 u   47   64  377  157.230  -181.56  40.011
#2603:c020:0:836 128.138.140.44   2 u   31   64  377   67.356  -183.90  34.736
-2603:c020:0:836 128.138.140.44   2 u   45   64  377   67.499  -140.08  28.859
+ntp7-2.mattnord 192.126.175.149  3 u   43   64  377   34.000  -181.35  43.799
#2603:c020:0:836 128.138.140.44   2 u   43   64  377   70.072  -178.10  38.423
#129.146.193.200 128.138.140.211  2 u   26   64  377   71.955  -171.97  29.660

Then I did some experimenting with just using my local clock.  That sync'ed
in a way that made sense so I added a second server to a public NTP server
that has a relatively low delay.  My ntp.conf looked like this:

server 192.168.44.1
setver time.cloudflare.com

I deliberately left the "iburst" off - I don't think it is a good ideal with
a 10Mb networked host. I left this run overnight and it was just what I would
expect. Here is what was displayed when I shutdown this morning:

$ ntptime

ntp_gettime() returns code 0 (OK)
  time e93675cf.a91361dc  Wed, Dec 27 2023  5:07:11.660, (.660452103),
  maximum error 426090 us, estimated error 2064 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -4321.771 us, frequency 13.463 ppm, interval 1 s,
  maximum error 426090 us, estimated error 2064 us,
  status 0x6001 (PLL,NANO,MODE),
  time constant 10, precision 0.001 us, tolerance 496 ppm,

$ ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*firewall.localh 192.168.44.6     2 u  750 1024  377    6.067   -5.128   1.340
+time.cloudflare 10.112.8.4       3 u  879 1024  377   25.840   -3.876   2.932

The max frequency I saw at Tue, Dec 26 2023 16:23:56 was 18.836 ppm, the min
I saw at Tue, Dec 26 2023 22:35:16 was 12.251 ppm and when I shutdown this
morning at Wed, Dec 27 2023  5:07:11 it was 13.463 ppm. Very stable to me.

Oddly enough, I think a simple config file like that looks a lot like
one I might have used back 20 years ago on the same hardware.

I may get the chance today to test the stock config with the "iburst"
removed from the line "pool 2.netbsd.pool.ntp.org iburst" to see if I
can handle a larger set of time sources, without generating my own
"network congestion" :)