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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:09 EST