Re: Can't sleep less than 20 ms

Bernd Paysan (bernd.paysan@gmx.de)
Mon, 5 Jul 1999 17:35:36 +0200 (MEST)


> > "timeout is an upper bound on the amount of time elapsed
> > before select returns."
> >
> > Thus select should return *before* timeout expires. Well, it doesn't
>
> sorry, but this way of reading makes no sense! in your reading it would
> be perfectly fine if select would return immediately, and it would be
wrong
> if returning some usec after timeout.
> and if you directly consider the need of delays/sleeps, upper bounds
make
> no sense and you can't guarantee them -- but sleeping _at_least_ some
> period of time is perfectly reasonable and it's just implemented this
way.

ObMontePythonArgument: No, it isn't. Real-time systems have something one
call "deadline schedule". You want to be woken up at least at e.g. 7:00,
because you miss the bus if your alarm clock rings later. If you take the
specification literally, it would make sense if the alarm clock rings
immediately, because then you still can busy-wait for 7:00 am. But after all, your
alarm clock has a precision (10 ms in case of Linux). So it makes sense that the
alarm is generated at the last tick before your deadline expires. You want
to sleep as long as possible, and still be woken up before your deadline.
That's what the system shall provide.

Some requests certainly are bogus, i.e. you can't expect select to return
before it has done all the work it needs to do (i.e. otherwise a select with
timeout 0 should return immediately without checking for the file
descriptors - that's wrong, it has to check the file descriptors first. Waiting for a
negative amount of time obviously is bogus, too).

> select either waits until the status changes, _or_ it will time out.
> `timeout' is an upper bound how long to _wait_ before timing out and
returning.
> but select obviously can't guarantee that it will return before
`timeout'
> is over.

Well, with reasonable timeouts, and idle CPU, select *can* guarantee what
you say is impossible. I'm doing this for years now. Well, I just subtract
20 ms from the deadline (well, not 20 ms, I *measure* the worst case timeout
and subtract that, since there is a change to fix it), and call select with
that parameter, but it works. I'd rather have an absolute time for select to
timeout instead of a relative (since then I don't know when select adds the
current time to the delta), but that's just a small detail.

I've already prepared a patch sometimes ago, and I'll prepare a patch for
the current kernel, if there are people out there that want it my way. I'm
not writing one for myself, since I've a workaround. And well, some silly
apps assume that 1 ns delay is sufficient to give away the CPU. They are really
surprised if select returns after well more than 1 ns, but less than 20 ms.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Sent through Global Message Exchange - http://www.gmx.net

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/