> Steve Underwood wrote:
> > > > > I hate to cite it, but people should read the manpage before they
> > > > > implement something. The manpage of select is quite clear about what the
> >
> > Yes, and some people think before they write. This is not a real time system.
> > There are _no_ upper bounds on _any_ execution times. Scheduling is totally
> > "best efforts" based.
>
> Linux doesn't do it's best efforts to ensure that select returns as
> specified in the man page. Even on an unloaded system, it waits between
> 10 and 20 ms longer than the specified timeout (depending on when the
> next timer interrupt is due). This is my complaint (and the complaints
> of the original poster).
>
> It's perfectly ok to have higher priority tasks preempt lower priority
> tasks, which causes unexpected delays to the lower priority tasks - this
> has nothing to do with select(2) semantics. But it is *not* ok to
> declare darkness as standard and don't try to do the best. Especially
> when it is only two lines of code to change.
>
> BTW POSIX: the single unix spec v2
> (http://www.unix-systems.org/single_unix_specification_v2/xsh/select.html)
> sais
>
> "If the timeout argument is not a null pointer, it points to an object
> of type struct timeval that specifies a maximum interval to wait for the
> selection to
> ^^^^^^^^^^^^^^^^
> complete. [...]"
>
> Contradictionary, it later sais
>
> "Implementations may also place limitations on the granularity of
> timeout intervals. If the requested timeout interval requires a finer
> granularity than the implementation supports, the actual timeout
> interval will be rounded up to the
> ^^^^^^^^^^
> next supported value."
>
> Rounding down would support the "maximum interval" above, but after all,
> if the app knows about the granulatrity, it can do the rounding itself,
> and isn't affected by this bogus rounding of the OS. Personally, I would
> prefer something that works with either the microsecond patch or the
> standard distribution, without checking the actual granularity by the
> app before.
>
> This is what Linux should do: try its best to ensure that select()
> doesn't unnecessarily wait longer than specified. If higher priority
> tasks preempt - well, that's live. But if there are no higher priority
> tasks, return as late as possible, but before the timeout expires.
>
> The Linux code now is just one off. Is this so difficult to accept that
> it is one off even after years of use? Can't it be fixed without harsh
> words?
>
> --
> Bernd Paysan
Yes the documents are poor. They should be more detailed, and fully describe what
the system does. However, they should actually be describing what happens now. Just
*think* instead of complaining. It can't be better than it is. If you want tighter
control you need something other than Linux, Unix, NT, Mac OS, etc. You need
something like VxWorks, and *extreme* control over what runs and when.
Consider this. The clock ticks at 100Hz. Sometime during the current 10ms interval
I start a 10ms timeout. The system knows not when. The system *must* add one to the
timeout to allow for that ambiguity in the start time, to ensure the interval is at
least what was requested. If the system is really lightly loaded and I keep
restarting 10ms timers every time they expire I will keep hitting a point early in
a 10ms interval, and the actual delay will be 20ms every time. Just like sending
voice over a non deterministic medium like an IP will never give predictable
quality, low delay audio on a non-real time system will never work in a smooth
predictable way. It wasn't one of the design goals.
Bottom line: with a 100Hz system clock a Unix (or for that matter NT) like system's
best effort at a continously restarting 10ms timeout on a lightly loaded machine is
actually 20ms.
Steve
-
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/