Re: [Xenomai-help] WG: Xenomai vs. RTAI

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- 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 --]