Just for background: I am *not* a multimedia, audio, or anything like that
guy. My most-used applications are gcc and a news/mail program (running
under dosemu, btw).
yodaiken@fsmlabs.com wrote on 01.07.00 in <20000701160143.A29436@hq.fsmlabs.com>:
> I don't know what a "specifically RT technique" is and I don't care
> how its done -- if the kernel can promise to always respond to an interrupt
> within some bound, then the kernel offers a hard realtime guarantee.
> And, for what it's worth, my professional opinion is that this is incredibly
> hard to do and never worth doing in a kernel that also wants to offer
> high speed networking, files systems, and guis.
FWIW, a kernel that cannot *at least* guarantee this will happen in
significantly more than 99% of the cases is broken for *every*
application.
According to the "hard real time" definitions given by, say, Larry,
*every* task is a hard real time task. There is *no* task that doesn't
have a deadline.
Those deadlines are of differing tightness (from microseconds to days) and
they are of differing importance - partly because the tasks themselves are
of differing importance, partly because the consequences of failure rates
differ. (And *everything* has failure rates. There is no perfect algorithm
in the real world.)
Oh, and 99% is a really crappy percentage. 1% of a year is nearly four
full days. 1% of a day is more than a full quarter hour. 1% of a 25*80
screen is 20 characters.
> I'm sure Ingo will tell you that his patch is designed to make long
> latencies _rare_ not impossible.
And that's exactly what is needed in the real world. IMO.
MfG Kai
-
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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:10 EST