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
On Sat, Dec 30, 2023 at 10:44:52PM +, Taylor R Campbell wrote:
> Note: I am NOT proposing any substantive changes to the implementation
> of the allocator -- I'm just proposing that we go back to the old
> _interface_, using the new pool-cache-based _implementation_, and to
> add
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
I propose to deprecate the kmem(9) interface and go back to the
malloc(9) interface.
1. The main difference is that the malloc(9) interface enables
attribution of memory usage: how many bytes have been used for this
purpose vs that purpose, partitioned by named malloc tags like
M_MBUF
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
>
16 matches
Mail list logo
