Messages in this thread | | | Date | 02 Jul 2000 11:29:00 +0200 | From | (Kai Henningsen) | Subject | Re: a joint letter on low latency and Linux |
| |
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/
| |