* Re: [Xenomai-help] WG: Xenomai vs. RTAI
2006-08-09 9:59 [Xenomai-help] WG: Xenomai vs. RTAI Roderik_Wildenburg
2006-08-09 10:40 ` [Xenomai-help] " Bernhard Walle
@ 2006-08-09 15:41 ` Jan Kiszka
1 sibling, 0 replies; 4+ messages in thread
From: Jan Kiszka @ 2006-08-09 15:41 UTC (permalink / raw)
To: Roderik_Wildenburg; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 5827 bytes --]
Roderik_Wildenburg@domain.hid wrote:
> Is there a summary of the advantages of Xenomai vs. RTAI ?
> I asked Google and my mail archive about this question but wasn?t very succesful.
Probably, because there hasn't been an open and broader discussion on a
public forum yet.
> As far as I know, very much which is true for Xenomai is true for RTAI too (userspace realtime, mixing realtime and linux systemcalls, multiple skins).
RTAI used to know skins as well - due to the existence of Xenomai or
RTAI/fusion in earlier versions. Now it only knows its own API in its
various revisions, RTDM (which seems to be in a good shape according to
the feedback of RTnet users), and a POSIX wrapping layer (currently
gains a rework/fixing).
> I did not work very much with RTAI (just with kernelspace applications and not with LXRT), so I don?t know the disatvantages/advantages of RTAI and its prakticability regarding user space support, mixing systemcalls, ...
>
> Perhaps somebody with background in both worlds (probably most of you ?) could give me some arguments why Xenomai is the better choice (especially practicability of the user space support is interesting for me; with Xenomai it is very easy to manage is it the same with LXRT ?).
Well, you already know most of my arguments, but I will try to repeat
them for all readers (and Google...). Hope I will stay objective, but
everyone should recall that I'm fairly biased now. :)
o Code organisation and style:
You may recall my example of the scheduler cores, but I think
everyone can repeat it with arbitrary code: pick two files from both
projects that deal with a similar topic, compare their styles and
then try to grab roughly what they do (start e.g. with [1] and [2],
then step down the layers). Ask yourself where you would prefer to
trace down problems if you ever have to (bugs can be everywhere).
o Development model:
RTAI's development is widely, today almost exclusively driven by the
immediate needs of its maintainer. Xenomai is aiming at a far broader
usage, including a smooth exploitation of upcoming preempt-rt.
As long as we used RTAI (2001-2005), we always faced quality issues.
I think I'm allowed to grumble here as we (University of Hannover)
actively worked on fixing them over the years. Unfortunately,
continuous changes on the RTAI core didn't let things converge, so we
finally migrated our robots to Xenomai. I'm twiddling thumbs since
then - ok, only virtually... ;)
And this is also attracting significantly more core contributors to
Xenomai. "Human resources" are most precious (not only) in this
domain, and I consider Xenomai in a far better position here (though
we will likely need additional resources in the future given its good
growth rate).
o Architecture support:
I predict RTAI will stay locked on x86 and maybe x86_64 (once we have
a recent I-pipe patch for that arch). That tightly relates to the
points above. No one is in sight to start an update of, e.g., PPC
over latest RTAI. Recently someone worked on an ARM update, but only
picked an outdated Adeos patch as platform and still struggled with
getting things clean on the RTAI side.
In contrast, Xenomai is in use over PPC[64] for quite a while now,
some ARM subarchs as well, we have Blackfin that is also officially
advertised by Analog Devices, and IA64, more should follow. There
must be some reason.
o Technical features:
As far as I can tell, there are two major RTAI features that are to
some degree advantageous compared to Xenomai: immediate IRQ
dispatching and direct syscall vectoring. It was claimed that they
have noticeable latency advantages, specifically on low-end. My last
comparison of RTAI-3.4 from CVS and Xenomai 2.2 from SVN a few weeks
ago showed about 10% better worst-case latencies of RTAI under load
on an oldish Pentium 133 MHz. Given the lost cleanness of design, I'm
absolutely convinced that gain is not worth its price. E.g., direct
syscalls seem to be one reason why gdb is not always working with
LXRT processes. But I'm biased, please do your own tests as well.
Since the requested major modification of the I-pipe model
(design-wise, not code-wise) got rejected for good reasons, there was
no more feedback from RTAI at least on this vital commonly used
component. We've recently identified an issue of the x86-2.4 I-pipe
patch. RTAI just solved it on its own instead of informing the Adeos
group so that it can be fixed for all users. Due to this lacking
cooperation, RTAI can only try to catch up the pace that is made by
Adeos/I-pipe today. Future kernels will require evolution of I-pipe
and its users (e.g. adoption to the GTOD infrastructure). It's
logical now that Xenomai will continue to be first in adopting this.
And then there is the flexible skin construction kit under Xenomai.
>
> And now something completly different, something more idelogical ;-):
> Wouldn?t a bulletin board or a WIKI be a better form of dicussion respectively knowledge base than a mail archive. The background for this question is, that allways when I start a new stupid question I can?t be sure whether this question hasn?t already been dealt with, as my mail archive isn?t complete and also not very good searchable.
Full ack. I've brought up the topic "wiki" a few times as I think it
would be helpful for several purposes.
Bruno, are you listening? Would it be feasible to set up a wiki on
xenomai.org?
Jan
[1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/skins/native/sem.c#L347
[2]http://www.rts.uni-hannover.de/rtai/lxr/source/base/ipc/sem/sem.c#L562
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread