Messages in this thread | | | Date | Fri, 23 Jul 1999 22:23:57 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
Sam Roberts wrote: (...) > Sorry. If it gets your job done, great! I just think its an unfortunate > limitation of Linux. That Linux is optimized for throughput is great > for servers, and thats important.
Agree, and I'm afraid this is what keeps RT from standard Linux.
> For personal workstations I don't think > its great. If you lost 10% performance and gained guaranteed maximum > jitters in the 1-3% range, I think that would be great for the multi-media > stuff thats becoming more and more part of desktop systems. And make it > more useful for soft real-time systems as well. > > As for the parts of Linux, like the scheduling alogrithm, that appear > to be optimized for multi-user time sharing systems, thats flat-out > archaic, in my view. Maybe I'm wrong about this, but when you're the > only person at the console, "fairness" in sheduling is a little less > necessary: you started the damn thing, if you think its taking up > too much time from your sound-card, lower its priority!
I don't fully agree here, though... If it's not really the only way, I think the user should be relieved of tasks like figuring out why some real time applications are having problems. To us it's just a matter of finding out who's messing with our real time tasks and lower it's priority, but for the non-guru end user, this must be dealt with automatically by applications. But would an API that allows some applications to mess with low level system settings be a very nice thing to have around? Perhaps it would, but the idea makes me a bit nervous...
> > 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: > > No indeed! > > > 1) Soft real time > > * Typically ms precision timing. > > * No guaranteed deadlines. > > I totally don't agree with "no guranteed deadlines", sorry. My last > company made remotely operated undersea vehicles (robots... they had > manipulators and lots of sensors). Its under water, nothing moves very > fast, so 50Hz control frequencies were common. That's 20 ms intervals. > However, *guranteed* response to error conditions and hardware failure was > required, that response had to be sub-second response, not > sub-microsecond, but it *still* had to be guranteed. Its soft realtime, we > didn't need 830 ms (+/- 3.25ms), but the O/S heading to sea, flushing its > disk cache, and blocking our A/D task for 1 1/2 seconds would make the > response noticeably choppy. Not having background data logging impact > control loops was also important, even if the loops were only 50Hz. And > controls engineers always want faster loops, they're never happy.
Well, if there is a truly guaranteed maximum scheduling latency, I guess it could be called hard real time... But I wouldn't call it reliable if you can't disable any subsystem that *could* cause a missed deadline. Accepted reasons for missed deadlines are system shutdown, hardware failure and that kind of things; not anything that could possibly happen on a working system.
> > A good multimedia OS would probably support both hard real time and an > > intermediate level with low average latency, with reasonable peaks. > > Reasonable is NOT 50 ms every now and then! That's the problem with most > > OSes. > Agreed. > > > //David > > 'ciao > Sam >
//David
- 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/
| |