Re: Clock drift and other open issues: Collecting information

[Anders Magnusson <ragge%tethuvudet.se@localhost>]

Physical amount of memory do not have anything to do with exhausted 
virtual memory.
Please check your limits (% limit)

-- Ragge

Den 2023-12-30 kl. 13:48, skrev Johnny Billquist:
> 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