Messages in this thread | | | Date | Sat, 1 Jul 2000 16:13:20 -0400 (EDT) | From | Gregory Maxwell <> | Subject | Re: a joint letter on low latency and Linux |
| |
On Sat, 1 Jul 2000, Larry McVoy wrote:
> > 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.
I agree here. Still, the matter remains: Is a bog-standard timeshare OS with absolutly no latency guarentees actually a useful computer system today?
I contend that since we've left the days of batch processed punchcards and computers in ivory towers, people have wanted some kind of latency guarentees, if they didn't why have a schedular at all? Software is fastest without all those context switches.
All of your handwaving about the evils of preemption and that any tasks that requires a responce time is hard realtime ignores the fact that almost every thing that Linux is used for is actually hard-realtime.
Do you think that a Linux server would not be considered a failure if it ocasionally failed to respond to syn packets within 10minutes?
Do you think that a Linux desktop would not be considered a failure if the mouse pointer ocasionally froze for two minutes?
etc..
Of course Linux can't be all things to all people, so someone must decide what is acceptable and what isn't. The audio people need <5ms, preferably less then 2ms. This isn't that big of a request when you consider that 1) they don't specify hardware (they are perfectly happy to require hardware 100x faster then what we were using 5yrs ago) 2) rare falure is toleratable (if there is a glitch, the software will recover, it simply has to have a higher MTBF then most of the musical intrstuments).
This makes their requirements quite different then most RTlinux users who typically want an embeded 486 (or simmlar) to perform tens of thousands of simple microsecond accuracy requiring tasks per second where a failuer could mean the loss of thousands of dollars.
- 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/
| |