Re: PSA: Clock drift and pkgin

Mouse wrote:

> Agreed.  ITIMER_REAL in the form I've been arguing for is of little
> help to a process that wants timer ticks separated by a hard minimum
> interval as seen by the signal handler.  At least when using
> it_interval to get repeated signals.
>
> But then, so is every other ITIMER_REAL I've ever used.

Maybe a possible answer/hack is a new timer like ITIMER_MOSTLY_REAL or
ITIMER_TICK or some variation thereof, which doesn't change existing
semantics for the current timers?


The original discussion that lead to this was timekeeping on a simh vax
running on amd64 where both had HZ=100.  We also have archs like pmax
that use HZ=256 and alpha that use HZ=1024.  Timekeeping isn't going to
work well on those where the requested HZ is greater than the host HZ.
Similarly, the discussions on this thread aren't going to help a 100 HZ
simh vax keep time any better if run on a shark with HZ=64(!).

qemu uses ppoll() which is implemented with pollts() to do emulated
timers, so that doesn't help here.  I don't know what simh uses, nor
any of the other emulators.

I have a grotty hack that attempted to spin if the requested timeout
was less than a tick based on what DragonflyBSD does.  It mostly
worked for simple tests but I haven't tested it seriously.  It's at
https://www.NetBSD.org/~simonb/pollfixhack.diff . This is potentially
another direction until we get a pure tickless kernel...

Cheers,
Simon.