Messages in this thread | | | Subject | Re: a joint letter on low latency and Linux | Date | Sat, 01 Jul 2000 13:43:01 -0400 | From | Paul Barton-Davis <> |
| |
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/
| |