Re: PSA: Clock drift and pkgin

On Thu, 21 Dec 2023, Jan-Benedict Glaw wrote:

> > > ntpq> pe
> > >      remote           refid      st t when poll reach   delay   offset  jitter
> > > ==============================================================================
> > >  [...]           [...]            3 u  261 1024  377   26.436  -50773. 2181.67
> > >  [...]           [...]            3 u  235 1024  377   22.300  -50785. 2183.03
> > >  [...]           [...]            2 u  284 1024  377   19.222  -50763. 2165.15
> > >  [...]           [...]            1 u   57 1024  377   26.263  -50390. 1765.14
> 
> Looking at the high jitter times...  I guess you have serial console
> and SSH access to that box?   If you compare responsiveness of both
> ways, do you generally feel an unreasonable jitter and/or delay over
> SSH (ignoring the initial login times of course XD)? Or is ping'ing
> the box unreasonable? Ie. I suspect a general interrupt handling issue
> somewhere, with "bad timekeeping" possibly only being a visible side
> effect.

 The box has always felt to operate smoothly in interactive use as per its 
performance capacity.  The console is awful of course at its 9600 baud 
rate.

 There are occasional surges of break-in attempts coming over network 
(which are hopeless by any means, as they use the wrong protocol for the 
listener at the port attacked) at which point the system does become less 
responsive.  I can't rule out such an event happening between two days ago 
and yesterday.  That ought not to have affected NTP though as the daemon 
runs at high scheduling priority and then under mlockall(2), so it should 
not be affected even by thrashing in the swap.

 In any case lost interrupts won't cause the clock running fast.  It's 
now:

Thu Dec 21 12:28:56 UTC 2023

on lizzie vs:

Thu 21 Dec 12:28:02 UTC 2023

actually, so the clock has gained almost a minute now over at most two 
days since `ntpd' gave up.  Perhaps the tick should be adjusted by hand, 
hmm:

# sysctl kern.clockrate
kern.clockrate: tick = 10000, tickadj = 40, hz = 100, profhz = 100, stathz = 100
# 

 NB SSH connections to lizzie are instantaneous owing to SSH multiplexing, 
absolutely necessary for remote regression testing:

$ /usr/bin/time ssh lizzie true
0.00user 0.00system 0:00.67elapsed 0%CPU (0avgtext+0avgdata 9216maxresident)k
0inputs+0outputs (0major+188minor)pagefaults 0swaps
$ 

-- not even a second elapsed for the whole remote command.

  Maciej