A comparison Of Hard Real-Time Linux Alternatives

An anonymous reader writes "This study compares the real-time capabilities of various Linux kernels. It was part of a project to upgrade the control software in water-wave generators at research institutions around the world. The results of the study were used by Akamina for the selection of a new RTOS for the control system upgrade of Canada's largest hydraulics and coastal engineering laboratory, the National Research Council Canadian Hydraulics Centre in Ottawa."

LKML discussing RTOS as well.

[Curtman]

Kernel Traffic has a pretty lengthy summary [kerneltraffic.org] of some discussion on the Linux Kernel Mailing List about the state of Real Time capability in the kernel as well that I found pretty interesting.

Summary: RTAI wins...

[quamaretto]

It would have been nice to see how all of these stack up to QNX and other real-time systems.

Meanwhile, I'll keep this article in mind for if I can ever get a better job position than "ASP.net slave".

Re:Summary: RTAI wins...

[bhima]

yeah... I took "Alternatives" to mean alternatives to Linux before I RTFA. Still it's a good read and worthwhile to me, despite the fact that only about 5% of my job is real time dependant.

A full blown RTOS can be overkill

[geirt]

A full blown RTOS is overkill for many RT applications.

Many RT tasks (like the one used in this article) can be described as:

Wait for IRQ. Do something *NOW*. Wait for IRQ

These tasks can be supported by the rtirq-patch [t-online.de]. rt-irq is a very small patch that allows just that (and nothing more). It would be nice to add rtirq to the comparison.

Not good result is it?

[raffe]

Conclusions

Based on the latency measurements made:

1. Of the options considered, only Linux 2.4 with RTAI meets the latency requirements for a real-time 100-Hz control system
2. Only Linux 2.4 with RTAI provides what could be considered deterministic interrupt response times and task switch times
3. Linux 2.6 is the next best option for real-time control
4. The results for Linux 2.4 with LXRT indicate that LXRT can not be used for hard real-time systems
5. Linux 2.4 can not be used for hard real-time systems

Re:Not good result is it?

[amorsen]

Linux is a general purpose OS. It would be surprising if it did work for hard real-time out of the box. That said, the Linux kernel really does suck more than necessary when it comes to soft real-time. The low-latency patches for 2.4 help, but it is only recently that Ingo Molnar started doing the hard work for 2.6. He is going way further than the 2.4 low-latency patches ever did. If he manages to get his work into a shape fit for inclusion into the kernel, Linux will be very impressive for soft real-time.

Re:Not good result is it?

[hethopus]

It would be much nicer if they would compare to RTLinux, which is also linux-based though paid. RTLinux has a patented linux-as-a-process scheme and they claim to be ultra-fast...

Re:Not good result is it?

[cherberos]

which is basicly what RTAI also does. RTAI is even a fork of RTLinux ( if I recall correctly), although nowadays RTAI incorporates some things different. They were also the first with 2.6 patches, if I recall correctly. Btw, FSM labs, who maintain RTLinux, also offer a GPL-edition for download.

Missing RTLinux

[Anonymous Coward]

How can you do a good comparison of Real Time Linux capabilities, without including RTLinux? RTLinux is used in Bluecat RT, one of the more widely used commercial Real Time linux distros. For that matter, LynxOS would have also been a good one to use. It is difficult to make a comparison of Hard Real Time Linux, when you only have one Real Time Linux version to compare with... odd.

Re:Missing RTLinux

[dmh20002]

problem is RTLinux isn't free as in beer. or if it is, where do I download the iso's.