Re: Clock drift and other open issues: Collecting information

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 
>>> <[email protected]> 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
>>>
>>>
>>
>