In <00070900012800.02351@localhost.localdomain> David Olofson (david@gardena.net) wrote:
DO> On Sat, 08 Jul 2000, Khimenko Victor wrote:
>> In <20000708150210Z31499-532+18397@nic.funet.fi> Juhana Sadeharju (kouhia@nic.funet.fi) wrote:
>> >>From: Andrew Morton <andrewm@uow.edu.au>
>> >>
>> >>doing silly things, the scheduling latency is reliably 4 milliseconds on
>> >>a 500MHz machine. Very occasionally reaches 7 millisecs. It has been
>>
>> > Lets talk about 7 ms latency only -- 4 ms is useless information in audio
>> > software which has to be 101% reliable.
>>
>> Sorry. It was said 1000 times already but I can repeat once more just for you:
>> 101% reliability => HARD real time => RTLinux. Period. If you NEED 101%
>> reliability then stop even THINKING about normal Linux already. It's NOT
>> for you.
DO> If Ingo's patch didn't provide hard real time, neither does RTL.
Wrong. Ingo patch was cooked up with help of benchmark and DOES NOT have any
strong design under it. Unfortunatelly THE ONLY thing that can be proved with
benchmark is UNAVAILABILITY of hard real-time, not AVAILIABILITY of anything.
DO> It's just a matter of what kind of peak latency the application
DO> requires.
Not at all. It's matter of guarantee. RTLinux CAN guarantee real-time (modulo
bugs) - it was designed for it. Ingo patch CAN NOT. It fixes places which is
known (more or less known, raither less then more; but it's other sory) to be
bad for latency. It does not guarantee yu anything - it's pretty possible that
some other software/hardware configuration will trigger situation where (even
with Ingo patches!) Linux will not respond for second or so. It's does not even
gurantee that on some weird (for you but not for user) configuration we'll not
get such drop-outs for every minute or so. It's just quick hack "to make it
wotk here and now" - nothing more.
DO> ********************************************************************
DO> The reliability is a function of the peak scheduling latency vs. the
DO> maximum latency that the application can deal with.
DO> ********************************************************************
Yeah. And Ingo patch DOES NOT guarantee you peak sheduling latency. Neither 5ms
nor even 1s. Want to see sluggish system with Ingo patch applied ? I can cook
up kernel module to make such a system in minutes. Now take look on number of
available drivers. Do you really assume there are NO drivers/filesystem/modules
who will make system sluggish with Ingo's patch ? You are joking, right ?
And if you can con induce user to not use ANY such "bad" module (or perhaps
even program - I'm quite sure some stupid program can trigger high latency
as well even with Ingo patch) then why the hell you can induce the usage user
to use your own "patched for this great application" kernel ? Gosh...
DO> At some point, the biggest problem will be hardware failures rather
DO> than missed deadlines, so there can never be exactly 100%
DO> reliability.
Oh yeah. Just there are difference betweek more-then-5ms-latency-once-per-week
and 1sec-latency-once-per-minute . Ingo patch claims to give you first thing
while in fact in quite likely situation it'll give you second. RTLinux does
not suffer from such problem.
DO> That's not really interesting to this discussion though,
It IS interesting. The more discussion progresses the less likely standard
linux looks like good platform for your application. First you need 5ms latency
in application without disk I/O, then you need 5ms latency for network
application, now some developer request 101% reliability. It looks more and
more like request for RTOS to me. And Linux is NOT RTOS. For better or for
worse it's not RTOS and not trying to be RTOS. Larry's initial decision of
request ("Other operating systems offer "soft realtime" and we don't want to
port our code from that to the RT Linux model" and translation: "other
operating systems have made poor design decisions, let's try and pressure
Linus into doing the same thing with Linux") looks more and more justified.
DO> so lets return to real life: Thorough testing of Ingo's
DO> patch has been done,
Yeah ? With how much systems and how much @##$$% drivers, third-party modules
(like softmodem ones) and how much weird programs (like VMWare) ? I repeat:
if you can control other parts of user environment then why you can not control
his choice of kernel ?
DO> and the results indicate that the timing is deterministic enough to be
DO> considered hard real time, for all practical matters.
Let me not believe in it. I'll put this 8 years old IDE without DMA support
and weird timing requirements (so you can not even use unmask irq hack) in my
700MHz Athlon system and your 5ms goal is way out of reach. And if you can
control THIS aspect of system then why you can not control user's kernel
choice ?
DO> The Linux/lowlatency peak latency is a lot higher than that of RTL,
What is MUCH more important there are no guarantee.
DO> BUT the relation between multimedia and robotics timing requirements
DO> is in the same order of magnitude! If you need RTL for "100%"
DO> reliable RT audio a about 1000 schedules/s, what do you use to
DO> control an industrial robot at 10000 schedules/s...?
If it's true that it's the end of story - Linux will not suit you, go use
RTLinux or some other OS.
>> Of course. It's easy. Use RTLinux. You need it anyway (as you said you need
>> 101% reliability) so what's the point of discussion at all ?
DO> Speaking for myself, the point is that
DO> * Ingo's lowlatency patch *does* provide adequate quality real time,
In lab (i.e.: in strictly controlled environment), not in real world.
DO> * it doesn't require porting code to a different environment,
Yeah. "Other operating systems have made poor design decisions, let's try and
pressure Linus into doing the same thing with Linux".
DO> * it doesn't break system security and stability entirely, as is
DO> the case when the code has to run in unprotected kernel space.
It just adds god knows how much petential deadlocks - not a big deal, really.
"Lets add potentially dangerous code so millions will suffer and thusands will
benefit". Does not look like good deal to me.
DO> Ingo's lowlatency patch *did* achieve the goal of taking the latency
DO> to professionally usable levels, and even below the previously
DO> "multimedia OS record" of 3 ms, held by BeOS.
Benchmarketing, yeah ? Not @ lkml, please.
DO> It even did so without any messy "direct access" API, or working around
DO> the normal driver API.
If it's so great for YOU then use it. If you push EVERYONE to use it... It's
other story (see above).
DO> I'm not saying that this justifies messing up the mainstream kernel
DO> - I fully agree that lowlatency should be implemented in an
DO> acceptable way. But to dismiss "multimedia class" hard RT SCHED_FIFO
DO> as impossible to do is to ignore facts. Maybe it IS impossible to do
DO> in a nice way, and maybe it'll never go mainstream because of that,
DO> but the figures we've seen, and the fact that Ingo's patch got us all
DO> the way performance wise, indicates that it's not totally hopeless.
May be. But again may be not.
DO> Either way, the only way to get *anywhere* is to dig in and hack some
DO> code! I'm drowning in work and projects, and trying to understand the
DO> code and do some real work seems to require optimizing my sleep away.
DO> *hrmpf* OTOH, I might be able to take some vacation soon... :-)
DO> Any guesses as to when it'll be definitely too late for this kind of
DO> patches for 2.4?
WHAT kind of patches ? Few (really few) small, justified changes can slip
in 2.4 at any stage. Deep rework of linux internals (if there are no way to
fix problem with few simple kludges - and by few I mean few: 3,5 may be 8,
but NOT 20 or 50) is 2.5 stuff anyway. Just remember that you can just one
try: if Linus will accept few such kludges and then week later you'll come
and say "oh, it was not enough, let's add some more" then most probably you'll
get nothing and Linus can even pull out old kludges - such scenario is not
impossible (= it happended). Of course Linus can accept some of proprosed
changes and then if it's not enough can accept some more from initially
proposed set - it's other story.
DO> PS. I'm not on l-k these days - please CC to david@gardena.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/
This archive was generated by hypermail 2b29 : Sat Jul 08 2000 - 20:47:46 EDT