On Tuesday 20 March 2001 17:49, Mel wrote:
> For soft time, the requirements for a POSIX compliant real time service
> appear to be complete in the scheduler with so much control over the
> scheduling algorithm and memory locking. However, it is not been explictly
> stated on any doc I have read that all the requirements for a soft
> realtime system are complete. Could someone clarify?
I'm not sure, but it might simply be something similar to why Linux itself
and Mesa aren't officially considered as POSIX and OpenGL implementations
respectively: The fact that such a claim would require permission from the
owners of the respective standards. That will usually require arrangements
that are incompatible with the licences of Free/Open Source software.
> Both RT-Linux and RTAI appear, to my eyes, to be very comprehensive but
> neither has become part of the stable kernel branch. Why is this?
It doesn't solve problems that the majority of users are having. (This
actually includes high end multimedia users and hardcore gamers as well;
they're better served by Linux/lowlatency.)
> Is there
> some bizarre rule out there that prevents hard real-time been a standard
> part of the kernel?
There's not exactly a rule, but the consesus after some discussion of this on
the kernel list was that including RTL or RTAI in the main distro would be
truly useful to very few, while encouraging crappy hardware (that require
hard RT drivers to work properly; DSP-less modems with insufficient buffering
is one example) and bad driver implementations.
> Is there a niche in there to fill which would involve
> adding just enough to the kernel that hard real time could be provided
> with system calls and then library support?
Not really. Most people don't have hardware nor applications to make use of
"�s class" hard real time. The only use for it on the average machine would
be driving soft modems, unbuffered I/O ports, PC speaker audio and other crap
that we don't want to encourage in mainstream machines anyway.
A hard or very firm "sub ms class" real time solution without driver access
restrictions would be much more useful to the multimedia users.
Linux/lowlatency is the most generic and best performing solution of that
kind so far, and it's not unlikely that it will eventually be a part of the
mainstream kernel, partly because it has a lot in common with more general
optimizations for high end SMP servers.
> For implementation of a hard real-time system, I would appear to be
> wasting my time starting from scratch considering how far RT-Linux and
> RTAI appears to have progressed. So I am searching for a TODO or wishlist
> that exists for either system that I could examine to see if I can pull
> masters material out of. Bear in mind that a Masters (in Ireland at least)
> is only about 18 months long and doesn't necessarily have to be ground
> breaking material.
>
> If it is a case, that working on a real time system is unfeasible, I'll
> start looking at other aspects of Linux that need working on such as
> trying to make the kernel pre-emptive, either fully pre-emptive or with
> fixed pre-emptive points. I understand this is one pitfall that prevents
> Linux been a truely real-time system.
It's also an issue that causes problems with SMP performance. Despite what
has been said about Linux and pre-emptive kernel design, Linux *is* already
partly pre-emptive when running on SMP machines. There have been various
suggestions regarding how this could be enabled on UP systems as well, which
would indeed help RT performance, but also performance in general in some
cases.
This, however, doesn't mean that Linux is going to be, or should be, fully
pre-emptive. Most of the reasons that caused Linus to take the non-preemptive
route in the first place, are still valid.
Meanwhile, looking at the latest Linux versions and the lowlatency patches,
it's clear that "sub ms class" hard real time is *not* a valid reason to go
preemptive - it's not required.
> If people on this list have projects around that they never found time
> for that involved real time systems, Linux and POSIX in some shape or
> form, I would love to hear them :-)
Well, I have one; the Audiality Project (which got me into all this in the
first place) but it has a heavy dependence on what eventually became MAIA.
(See .sig.)
The interesting part of that (WRT real time programming) would be SMP and
cluster support. I'm planning to eventually build a very high end audio/music
workstation with a bunch of workstation CPUs (probably PPC or Alpha) rather
than custom DSP hardware. Low latency audio processing on SMP systems and
clusters seems to be an area with next to no information on prior art
available, so it seems like I'll have to figure most of it out by myself,
unless someone beats me to it.
> Thanks for your time (not a pun)
Speaking of time; I wish it was as easy as installing RTL or RTAI to keep
track of *my* time! ;-)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
