Re: Clock drift and other open issues: Collecting information

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

Um. Correction - my simh 8650 instance only have 64M, but is running 
through the build just fine, while my 4000/90 with 128M is failing with 
memory exhausted.
swap is at 256M on each.

  Johnny

On 2023-12-30 13:37, Johnny Billquist wrote:
> 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 whenpoll 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