lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: a joint letter on low latency and Linux
Date
From
In message <200007011617.JAA05880@work.bitmover.com>you write:
>> I am nervous about this characterization. As I have said many times,
>> "hard realtime" normally *implies* a lot more than we need for
>> real-time audio+MIDI applications. All we need is guaranteed
>> scheduling response. We don't need QOS guarantees for any other
>> subsystems, for example (it would be nice, but its not necessary).
>
>"All we need is guaranteed scheduling response". But it's not real time.
>
>Those two statements are 100% at odds with each other.

Did you read what I wrote ? Did I say "its not real time" ? I've said
over and over that I am not interested in this kind of
classification. I'm interested in features and performance, not
semantics.

I said ""hard realtime" normally *implies* a lot more than we need".

The reason why I am not happy with thinking about this as "hard
real-time" is precisely that: making Linux hard real-time involves
fixing way more stuff than the scheduling response. RTLinux is
probably the right approach to producing a Linux-related OS that can
do hard-real-time in the sense that a user of QNX would want to hear
about.

But nobody here has said anything to convince me that RTLinux is the
right approach to getting the scheduler to be capable of making hard
real time response guarantees.

I am willing to be convinced of this, truly. However, the example of
BeOS keeps nagging me. Those guys do claim "guaranteed" response time
for audio+multimedia apps, but they don't claim to do hard real
time. So, by the terms that you've helped enforce here, either they
are lying, or there is some way to do one without the other.

--p

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.039 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site