Re: Clock drift and other open issues: Collecting information

[Johnny Billquist <bqt%softjar.se@localhost>]

After some initial messing around and trying to sort things out, my 
4000/90 also seems to be keeping time fine, and also are happy with ntpd 
running. Polling rate on ntp have dropped to 1024 for me as well.

So I'm not sure if there are any problems around this currently. There 
is clearly some problem when running under simh, but I think that seems 
to be a simh problem, and not anything with NetBSD.

Annoyingly, though, I can't do a native build on my 4000/90. I get the
"virtual memory exhausted: Cannot allocate memory"
error. Machine have 128M. However, my emulated 8650 (in simh) also with 
128M is building native just fine. Not sure if there is just some 
slightly difference in the amount of memory allocated inside the kernel 
between the two architectures at boot that makes the difference in the end.

  Johnny



On 2023-12-30 10:26, Jan-Benedict Glaw wrote:
> 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

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol