Messages in this thread | | | Date | Fri, 23 Jul 1999 03:57:23 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
Raul Miller wrote: > > David Olofson <audiality@swipnet.se> wrote: > > I think this whole discussion is beginning to get confused by different > > definitions of "real time". (Not the first time...) Basically, there are > > two kinds: > > > > 1) Soft real time > > * Typically ms precision timing. > > * No guaranteed deadlines. > > > > 2) Hard real time > > * Usually significantly better than ms precision > > * Guaranteed deadlines. > > Maybe three kinds, see: http://hegel.ittc.ukans.edu/projects/kurt
Yes, I've seen the KURT site, but not looked much closer at it.
Perhaps I should have mentioned Firm Real Time as a third kind. (It's more or less what I sugested for multimedia later on in the original post. However, I really don't like the normal mode/real time mode switching idea...) But as I was more focused on the issue that makes all the difference to some applications; guaranteed maximum latency; I didn't consider firm real time significantly different from soft real time. It is indeed in real life, but not to applications that really require hard real time.
//David
> <QUOTE> > Some types of processing (eg. multimedia) do not fit well into the > hard or soft real-time categories. The periodic requests made by > multimedia applications are sensitive to variations in timing. As > such, they are not well served by the loose guarantees provided by > soft real-time systems. Hard real-time systems are often faced with > providing guarantees at the expense of providing services. Thus, while > they can meet the timing requirements of a multimedia application, > many times they cannot meet it's other service requirements. For > example, real-time processes running under RTLinux have no access to > any of the Linux services. > > A purely binary distinction between hard and soft real-time is clearly > not acceptable for all applications. Many applications have > requirements spanning a continuum between the two. ... > </QUOTE> > > [With supposedly a demo where a modified xanim performs better on a > loaded system.] > > -- > Raul
- 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/
| |