Re: PSA: Clock drift and pkgin

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

On 2023-12-13 15:46, Anders Magnusson wrote:
> > > Do you have measurements that show clock drift under load?
> >
> > I was assuming he had. But in a sense, it also wouldn't surprise me. 
> > When doing things, the amount of time in system mode these days for 
> > NetBSD/VAX really bothers me. Sometimes I can observe it being at over 
> > 50% system time for longer periods.
> > And in Josh case, it's reporting over 50% in interrupt context, which 
> > *really* worries me, and suggests that would could easily be missing 
> > interrupts...
> Quite some time ago I was trying to profile the kernel (in vax), and 
> found that there are some places where the code implemented has ended up 
> very inefficient.  This is not noticed on any modern hardware, butthe 
> effect on vax is significant.
> IIRC one of the places was the in-kernel NTP code.  Taking it out had a 
> noticeable effect on kernel time used.
> Is the in-kernel profiling code is still available for use?

Interesting. I wonder how the in-kernel NTP code could be so costly?
Anyway, profiling is probably the most interesting thing we could do, if 
it's still possible.

> This was many years ago, I do not know what the state is now.

I don't think anything improved meanwhile, so I suspect whatever you 
found is probably still valid. And then probably more things have been 
added.

> Can also note that I once was trying to find what caused the clock drift 
> (has been present for quite some time) by adding code that was checking 
> for lost interrupts, but there were no missed clock interrupts seen. Did 
> not search any deeper after that.

If we don't have lost clock interrupts, the only source of drift 
(assuming we don't have ntp or something else setting the system up for 
slow time adjustment), would be the chrystal itself. I know that the 
chrystal used in VAXen aren't perfect, and you do have some drift from 
that. But that is completely independent of load.
But a drift of a couple of % would not be unexpected.

But if we can detect drift that is varying based on load, then it's 
something in the software causing us to miss interrupts, or something is 
tweaking time. Because otherwise it's very straight forward. Interrupts 
move the time forward, and they are very regular.

  Johnny

--
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