On Fri, 2023-12-29 22:07:54 +0100, Jan-Benedict Glaw <jbglaw%lug-owl.de@localhost> wrote:
> My result so far is that the 4000/90 as well as the /60 seem to
> properly keep time on their own (with a drift of some two to four
> seconds per day) and ntpd is capable of managing that. A bit on the
> odd side: It seems to not extend the poll interval beyond 128sec for
> useable peers, and I've (at max) only seen 256sec once for a claimed
> falseticker. OTOH, the amd64 Linux box will extend to the 1024sec
> interval soonish. (It seems the amd64 box stays *very* long with a
> specific pll freq, whereas the VAX systems keep adjusting it by minute
> details. I guess that's a related fact.)
One night later:
# ntpq -n -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
*78.47.168.188 17.253.14.125 2 u 525 1024 377 29.679 -0.042 0.379
-142.132.210.78 131.188.3.222 2 u 376 1024 377 27.807 +0.747 1.423
+82.165.57.232 129.69.1.170 2 u 438 1024 377 21.954 -2.096 3.417
-217.144.138.234 124.216.164.14 2 u 334 1024 377 20.691 -0.411 36.561
+75.119.140.230 36.224.68.195 2 u 748 1024 377 19.794 -0.207 0.572
# ntptime
ntp_gettime() returns code 0 (OK)
time e93a607d.8aae18ac Sat, Dec 30 2023 10:25:17.541, (.541719615),
maximum error 261529 us, estimated error 560 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset -879.658 us, frequency 32.676 ppm, interval 1 s,
maximum error 261529 us, estimated error 560 us,
status 0x2001 (PLL,NANO),
time constant 10, precision 0.001 us, tolerance 496 ppm,
This is the /60 while being idle. So let's start a loop with GCC.
MfG, JBG
--
Attachment:
signature.asc
Description: PGP signature