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/