Re: PSA: Clock drift and pkgin

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Specifically, under a kernel built with HZ=100, requesting signals
>> at 100Hz actually delivers them at 50Hz.  [...]
> This is the well-known problem that we don't have timers with
> sub-tick resolution, PR kern/43997: https://gnats.netbsd.org/43997

It doesn't need sub-tick resolution; one-tick resolution would fix the
problem.  The problem appears to be that an ITIMER_REAL timer can't
deliver signals more often than every second tick.

> In particular, there is no way to reliably sleep for a duration below
> 1/hz sec.

Nor does there need to be to fix this.  1.4T/sparc and /i386 get it
right, even when running with HZ=100 and requesting 100Hz SIGALRMs.
(My timer sockets get it right too, but their codepath is completely
different, depending on only timeout(...,0,1) (1.4T) or
callout_schedule(...,1) (4.0.1 and 5.2).

> Fixing this requires adopting an MI API and MD clock driver support
> for wakeups with sub-tick resolution,

You must be talking about something different from what I'm talking
about.

What I want fixed does not involve sub-tick-resolution timers at any
level.  If using setitimer(ITIMER_REAL,...) to request SIGALRMs every
tick actually delivered a SIGALRM every tick, I'd be fine.  But,
instead, doing that delivers a SIGALRM every second tick.

> which nobody's done yet --

Nobody's done the sub-tick resolution you're talking about, maybe.  But
1.4T long ago did what I'm looking for.  Something between 1.4T and
4.0.1 broke it, and it's stayed broken until at least 9.1, probably 9.3
based on someone else's report on port-vax.  (Okay, strictly, I don't
know that it's stayed broken.  It could have been fixed and then
re-broken.)

>>         } else if (sec <= (LONG_MAX / 1000000))
>>                 ticks = (((sec * 1000000) + (unsigned long)usec + (tick - 1))
>>                     / tick) + 1;

> Whether this is a bug depends on whether: [...]

I think that code is not a bug per se; for sleeps, that codepath
is...well, "reasonable" at the very least.  The bug is that it is
broken for timer reloads, but timer reloads are using it anyway;
whether you think of this as a bug in timer reloads or a bug in tvtohz
is a question of which way you prefer to squint your mind.

Always adding an extra tick may be fine for sleeps (though that's
arguable for short sleeps on a system with a high-res wallclock), but
not for timer reloads.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B