I believe you. But aren't we now getting into pretty realtime stuff? Not
sure NetBSD is at all suitable for such applications/environments. As
you say - if this only behaves acceptably if the system is not under
load, then it's not a solution I would go for.
But again - I guess we're talking
Johnny Billquist writes:
> Ok. I oversimplified.
>
> If I remember right, the point was that something sub 200ms is perceived
> by the brain as being "instananeous" response. It don't mean that one
> cannot discern shorter times, just that from an action-reaction point of
> view, anything below
On Saturday, December 30, 2023 at 10:43:34 AM PST, Martin Husemann
wrote:
> Kernels on that machines just would not run fully tickless.
That makes sense. I personallly would call that "tickless where possible", not
"fullly tickless".
On 12/30/2023 3:42 PM, Johnny Billquist wrote:
On 2023-12-31 00:11, Michael van Elst wrote:
Better than 100Hz is possible and still precise. Something around 1000Hz
is necessary for human interaction. Modern hardware could easily do
100kHz.
? If I remember right, anything less than 200ms is
On Sun, Dec 31, 2023 at 02:54:50AM +0100, Johnny Billquist wrote:
> Ok. I oversimplified.
>
> If I remember right, the point was that something sub 200ms is perceived by
> the brain as being "instananeous" response. It don't mean that one cannot
> discern shorter times, just that from an
Ok. I oversimplified.
If I remember right, the point was that something sub 200ms is perceived
by the brain as being "instananeous" response. It don't mean that one
cannot discern shorter times, just that from an action-reaction point of
view, anything below 200ms is "good enough".
My point
> ? If I remember right, anything less than 200ms is immediate response
> for a human brain.
"Response"? For some purposes, it is. But under the right conditions
humans can easily discern time deltas in the sub-200ms range.
I just did a little psychoacoustics experiment on myself.
First, I
mo...@rodents-montreal.org (Mouse) writes:
>> Modern hardware could easily do 100kHz.
>Not with curren^Wat least one moderately recent NetBSD version!
>At work, I had occasion to run 9.1/amd64 with HZ=8000. This was to get
>8-bit data pushed out a parallel port at 8kHz; I added special-case
On Sun, Dec 31, 2023 at 12:42:29AM +0100, Johnny Billquist wrote:
> > Better than 100Hz is possible and still precise. Something around 1000Hz
> > is necessary for human interaction. Modern hardware could easily do 100kHz.
>
> ? If I remember right, anything less than 200ms is immediate response
On 2023-12-31 00:11, Michael van Elst wrote:
On Sat, Dec 30, 2023 at 10:48:26PM +0100, Johnny Billquist wrote:
Right. But if you expect high precision on delays and scheduling, then you
start also having issues with just random unpredictable delays because of
other interrupts, paging, and
> Better than 100Hz is possible and still precise. Something around
> 1000Hz is necessary for human interaction.
That doesn't sound right. I've had good HCI experiences with HZ=100.
Why do you see a higher HZ as necessary for human interaction?
> Modern hardware could easily do 100kHz.
Not
On Sat, Dec 30, 2023 at 10:48:26PM +0100, Johnny Billquist wrote:
>
> Right. But if you expect high precision on delays and scheduling, then you
> start also having issues with just random unpredictable delays because of
> other interrupts, paging, and whatnot. So in the end, your high precision
On 2023-12-30 22:10, Michael van Elst wrote:
b...@softjar.se (Johnny Billquist) writes:
Being able to measure time with high precision is desierable, but we can
already do that without being tickless.
We cannot delay with high precision. You can increase HZ to some degree,
but that comes at
b...@softjar.se (Johnny Billquist) writes:
>Being able to measure time with high precision is desierable, but we can
>already do that without being tickless.
We cannot delay with high precision. You can increase HZ to some degree,
but that comes at a price.
On 2023-12-30 19:43, Martin Husemann wrote:
On Sat, Dec 30, 2023 at 06:25:29PM +, Jonathan Stone wrote:
You can only do tickless if you can track how much time is elapsing when no
ticks fire, or none are pending.
I don't see how to do that without a high-res timer like a CPU cycle counter,
On Sat, Dec 30, 2023 at 06:25:29PM +, Jonathan Stone wrote:
> You can only do tickless if you can track how much time is elapsing when no
> ticks fire, or none are pending.
> I don't see how to do that without a high-res timer like a CPU cycle counter,
> or I/O bus cycle counter,
> or
On Saturday, December 23, 2023 at 10:19:53 PM PST, Simon Burge
wrote:
> 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
>
On 2023-12-25 02:17, Robert Elz wrote:
Date:Sun, 24 Dec 2023 13:49:53 +0100
From:Johnny Billquist
Message-ID:
| In my opinion, all of these POSIX calls that take a time argument should
| really have been done the same as clock_gettime(), in that you
On Mon, 2023-12-25 00:26:34 +0100, Johnny Billquist wrote:
> But I think the suggestion that the time adjustment might actually be a
> source of the problem is interesting, and should be investigated. It just
> takes so bloody long to do a full build these days. I still haven't
> finished, and
On Sunday, December 24, 2023 at 02:43:55 AM PST, Johnny Billquist
wrote:
> Oh? So we are actually not POSIX compliant on that one? Interesting.
> (POSIX explicitly says that the timeout should be for an absolute time,
> which means that if you for example update the clock, moving it
>
Date:Sun, 24 Dec 2023 13:49:53 +0100
From:Johnny Billquist
Message-ID:
| In my opinion, all of these POSIX calls that take a time argument should
| really have been done the same as clock_gettime(), in that you specify
| what clock it should be based on.
On 2023-12-24 20:58, Jonathan Stone wrote:
On Sunday, December 24, 2023 at 02:43:55 AM PST, Johnny Billquist
wrote:
> Oh? So we are actually not POSIX compliant on that one? Interesting.
> (POSIX explicitly says that the timeout should be for an absolute time,
> which means that if you
On 2023-12-24 11:43, Johnny Billquist wrote:
On 2023-12-24 09:26, Michael van Elst wrote:
sim...@netbsd.org (Simon Burge) writes:
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.
On 2023-12-24 09:26, Michael van Elst wrote:
sim...@netbsd.org (Simon Burge) writes:
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.
simh uses pthread_cond_timedwait().
This
sim...@netbsd.org (Simon Burge) writes:
>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.
simh uses pthread_cond_timedwait().
This actually waits using TIMER_ABSTIME for a
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
In a discussion of timekeeping on emulated VAXen, over on port-vax@, I
mentioned that I've found that, on 4.0.1, 5.2, and 9.1, and, based on a
report on port-vax@, apparently 9.3 as well, there's a bug in
ITIMER_REAL signals (possibly on only some hardware - I've seen it on
amd64 and i386, and, if
41 matches
Mail list logo
