New to RTAI

Philippe Gerum rpm at
Thu Oct 7 16:14:39 CEST 2004

On Fri, 2004-10-01 at 18:24, Currie Reid wrote: 
> I am currently investigating real-time Linux solutions on a variety of
> architectures, including ppc, i386, arm and mips, for a variety
> of boards under each architecture.  Currently the best bet at this point
> seems to be RTAI, but what flavour?  RTAI 3 seems to have support only for
> i386 using ADEOS (trying to avoid RTLinux patent problems) but my first
> board is ppc.  Does that mean I should go the Fusion route?  One of the
> criteria that I've been asked to ensure is that whatever solution I come
> up with works with a 2.6.x kernel.  Fusion seems to offer more in this
> regard as it supports i386 and ppc under the 2.6 kernel without the sticky
> RTLinux patent problems (again because of its ADEOS base).
> Please excuse the newbie questions - I've tried to find the answers to
> these questions on the site, but the project seems to be moving so quickly
> that the documentation that is there is out of date.

If 2.6 is a prerequisite, then I'd say that choosing between 3.x and
fusion is basically a matter of selecting a software architecture that
fits your needs. Both provide kernel-based and user-space oriented
real-time support, but do not implement them the same way, mainly
because they had different initial goals.

Historically, 3.x and its predecessors - i.e. the original RTAI
technology - were primarily aimed at high performance, slicing
nanoseconds to get as close as possible to the hardware limits with
respect to latencies, and only relatively recently worked on a deeper
integration/cooperation of the real-time core with the Linux kernel. For
this reason, the 3.x core architecture has a monolithic design going
straight to the performance issues, and still has a strong x86 bias.

Ok, now the shameless plug. Meanwhile, the Xenomai technology which
underlies fusion - and was merged into the RTAI project 18 months ago -
has taken the exact opposite approach during its development: first, a
seamless integration of the real-time core with Linux has been reached,
then we have been working lately on the raw performance issues, granted
that the core Xenomai software already provided for determinism. The
reason for such approach is to be found in the initial goal of Xenomai,
which was to provide a framework for porting applications from
traditional RTOS like VRTX, pSOS+, VxWorks, ChorusRT (or even RTOS specs
like Arinc653 and uITRON) to a GNU/Linux environment. We wanted at that
time to be able to impersonate any kind of RTOS by emulating its API
over a generic core, and have this RTOS abstraction level intimately
integrate with the Linux kernel so that, like LXRT allowed before us, we
could escape the "FIFO hemiplegia", i.e. the need for splitting
real-time applications in two separate kernel and user spaces, only
communicating through a sub-optimal and non-deterministic data channel.

What fusion does better than LXRT though is preventing real-time tasks
which issue Linux system calls from being perturbated by non RTAI
activities. For achieving the whole thing, we went for a layered
approach. Anyway, everything is better explained here:

PPC-wise, 3.x continues the long time support of this architecture for
kernel-based tasks which has been available since the early days of the
RTAI project. fusion provides user-space support for PPC, but it has no
track record since it has been made available only recently.

To which extend fusion's layered approach is good or bad for
performance, whilst 3.x's entangled implementation is good or bad for
reliability remains one of our few but favourite trolls on the RTAI-dev
list :o)
This said, the way things work in this project causes improvements and
fixes made on one side invariably go to the other one when applicable,
which is largely made possible by the common base technology they share,
i.e. Adeos. 

IOW, whatever path you go down to, you will certainly have to take a bet
on the future :o)



More information about the Rtai mailing list