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
> So even though we added one tick, you can still get two timer events
> in much closer proximity than a single tick as far as the process is
> concerned.
Certainly. I think that's unavoidable without resetting the timer
inside the signal handler, or hard realtime guarantees (which are Not
By the way, I should point out that adding 1 tick to the reload of the
interval timer in no way gets you away from the possibility that you'll
get two timer signals with almost 0 time between them.
Because the simple truth is that it is completely unknown when the
program will actually get the
On 2023-12-23 23:05, Taylor R Campbell wrote:
The attached (untested) patch reverts to the old algorithm
specifically for the case of rearming a periodic timer, leaving the
new algorithm with +1 in place for all other uses.
Now, it's unclear to me whether this is correct, because it can have
> The attached (untested) patch reverts to the old algorithm
> specifically for the case of rearming a periodic timer, leaving the
> new algorithm with +1 in place for all other uses.
> Now, it's unclear to me whether this is correct, because it can have
> the following effect. Suppose ticks
> Date: Sat, 23 Dec 2023 12:24:08 -0500 (EST)
> From: Mouse
>
> >> } else if (sec <= (LONG_MAX / 100))
> >> ticks = (((sec * 100) + (unsigned long)usec + (tick -
> >> 1))
> >> / tick) + 1;
>
> > Whether this is a bug depends on whether: [...]
>> 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;
On 2023-12-23 17:39, Taylor R Campbell wrote:
Date: Fri, 22 Dec 2023 23:41:47 -0500 (EST)
From: Mouse
Specifically, under a kernel built with HZ=100, requesting signals at
100Hz actually delivers them at 50Hz. This is behind the clock running
at half speed on my VAX emulator, and quite likely
> Date: Fri, 22 Dec 2023 23:41:47 -0500 (EST)
> From: Mouse
>
> Specifically, under a kernel built with HZ=100, requesting signals at
> 100Hz actually delivers them at 50Hz. This is behind the clock running
> at half speed on my VAX emulator, and quite likely behind similar
> behaviour from
On 2023-12-23 16:53, Mouse wrote:
[...], but we are in fact rounding it up to the double amount of time
between alarms/interrupts. Not what I think anyone would have
expected.
Quite so. Whatever the internals behind it, the overall effect is "ask
for 100Hz, get 50Hz", which - at least for me
> [...], but we are in fact rounding it up to the double amount of time
> between alarms/interrupts. Not what I think anyone would have
> expected.
Quite so. Whatever the internals behind it, the overall effect is "ask
for 100Hz, get 50Hz", which - at least for me - violates POLA hard.
/~\ The
On 2023-12-23 14:35, Mouse wrote:
} else if (sec <= (LONG_MAX / 100))
ticks = (((sec * 100) + (unsigned long)usec + (tick - 1))
/ tick) + 1;
The delay is always rounded up to the resolution of the clock, so
waiting for 1 microsecond waits at
>>>} else if (sec <= (LONG_MAX / 100))
>>>ticks = (((sec * 100) + (unsigned long)usec + (tick - 1))
>>>/ tick) + 1;
>> The delay is always rounded up to the resolution of the clock, so
>> waiting for 1 microsecond waits at least 10ms.
But it is
Michael van Elst wrote:
> mo...@rodents-montreal.org (Mouse) writes:
>
> >} else if (sec <= (LONG_MAX / 100))
> >ticks = (((sec * 100) + (unsigned long)usec + (tick - 1))
> >/ tick) + 1;
>
> >which looks suspicious. If sec is zero and usec is
mo...@rodents-montreal.org (Mouse) writes:
>} else if (sec <= (LONG_MAX / 100))
>ticks = (((sec * 100) + (unsigned long)usec + (tick - 1))
>/ tick) + 1;
>which looks suspicious. If sec is zero and usec is tick, that
>expression will return 2
15 matches
Mail list logo
