Real-Time Linux Experiences?

fidget42 asks: "I was wondering what types of experiences people have had with using some of the 'real-time' variants of Linux. I have looked at some of the choices (RTLinux, RTIA, etc.) but would also like to tap the experiences of the Slashdot readers. I am not looking for an embedded solution (while I will be on a single board computer, it will not be for a 'set-top box'), but one that will live happily on a PowerPC running in a VME chassis or something similar. Have you had good luck controlling VME devices from within a real-time Linux system? What problems did you encounter? While I do not need to run hard real-time, I still need tight tolerances on my timing. Our current platform gives us 5ms of jitter per 50ms cycle (very bad) and we would like to get down to 0.5ms, or less, of jitter per 50ms cycle. I also need guaranteed deadlines. One vendor told me that '97% of the time, you should be able to make the deadline' but 97%, and should, is still not good enough. Any and all help would be appreciated."

experiences with pre-emptive kernel

[repoleved]

Well.. I know this isn't real-time linux, but it was much more real-time-ish than the vanilla kernel, so I'll just throw in my 2 cents here:

It worked. It worked pretty well. Video performance was very smooth, and over all it was very responsive. Once in a while, vmware would freeze up the entire computer because one of the modules didn't like being pre-empted, when swap was on, but that was pretty much the extent of my trouble.

So assuming that you won't be running vmware with the pre-emptive kernel, based on my solitary account, should should be good to go!

;-)

What some people think of Real Time Linux

[repoleved]

This web site might be helpful. Report on the 2nd Real-Time Linux Workshop [mlinux.org].

The Real-time Linux Software Quick Reference Guide

[repoleved]

Here's another useful article called 'The Real-time Linux Software Quick Reference Guide' [linuxdevices.com]

These guys might be able to help you

[repoleved]

Some students have been busy answering the very question being asked. They have been evaluating various real time linux versions. Check out this link for more information. [vmlinux.org]

RT Linux - good if you only talk to hardware

[motyl]

If you just need predictable timing and no IO, no memory allocation in real time, then both RTL and RTAI will work. RTAI has richer API. You will get below 20 us typical, below 30-50 us worst case delay (if you will not get PCI stalls (e.g. XFree 4.0 on some video cards)). You will have to recompile all the modules with RT kernel - any binary kernel module may contain cli().

Split your application cleanly between real time (put there only what absolutely neccesary) and all the rest.

And have a look into one shared mechanism - mbuff [unibas.ch]

Clarification

[fidget42]

For those who wanted clarification of my needs, I need to simulate an aircraft and its navigation sensors. First a preemptive strike, I am not writing a flight simulator (FlightGear does a wonderful job), but I need to simulate the aircraft as reported by its navigation sensors. Sensors such as intertial navigation (INS) or global positioning (GPS) systems have to produce their data at a very specific time interval (thus the 0.5ms jitter per 50ms period requirement). Since I have 50ms to do my computations, I am not so worried about the data being computed too late. I do need my data to be transmitted as close to its deadline as possible (jitter induces computation errors = a Very Bad Thing).

RT Linux

[Anonymous Coward]

The FIFO scheduling works ok, but my big beef is with dispatch latency - if you can deal with 1 or 2 msecs of latency, perhaps it's ok.

Beware of the serial driver which exhibits up to 10 msecs of latency!!

I'm not overly impressed so far. It's getting better, but has a long way to go - I would not get on an aircraft yet with an RT-Linux flight control system, but for soft real-time, it passes.

Just be warned about dispatch latency.

I would not yet trust it for hard real-time where there could be significant loss of assets or human life if a service deadline is missed - that's hard real-time.

Finally, the Linux community is totally ignorant of issues such as priority inversion -- they just don't get it!! Spin locks are not an answer to this problem and simply displays their lack of understanding.

The best thing about Linux is that it's FREE and with some hard work, some understanding of hard and soft real-time theory, the Linux multi-user beast can be tamed and put to work in an RT embedded system - be prepared to write your own drivers and dig into the kernel - I know, because I've done it a couple of times!

Beware of the "hype" from RT-Linux service companies that try and sell you support for a perfectly good FREE kernel and have no clue what real-time even is ... if you're going to pay that much, then I would advise a tried and true RTOS, but if you are willing to roll up your sleeves, understand the source, write drivers and deal with some issues like dispatch latency and lack of RT mechanisms (POSIX 1003.1b) and FREE is the right cost, then I whole-heartedly recommend Linux.

QNX if realtime UNIX is OK (not Linux)

[andaru]

Check out QNX if you can use a realtime UNIX instead of a realtime Linux.

The latest version is free, and the kernel is small.

I have not used the new free version, so I cannot say how it compares to QNX4, but QNX4 is fast, reliable (we have multi-node systems which have been running in the field for 3 years, constantly pumping audio (running radio stations) without a single hitch, even through multiple software upgrades (yes, we were able to upgrade the software while the network was controlling multiple on air stations) ), and is a hard realtime OS.

I don't know specs on the actual timing details, but I know that it gives guarantees and keeps them (which is mainly what makes it hard realtime - soft realtime would be, "we need to empty this buffer at least once every 50ms," while hard realtime would be, "we have a 2ms window every 50ms during which time we must read and reset this flag").

Anyway, there are lots of good things to be said for QNX, but you can find out all about it from their site, the QNX users group, etc..

So now you can hit Google to find out all about QNX.

Worst-case interrupt latencies - RTLinux and L4RTL

[Read The Fine Manual]

Have a look at this paper: ``RTLinux with Address Spaces'' [tu-dresden.de] by Frank Mehnert and others.

In this paper, we measured ``worst-case'' interrupt delays of two real-time systems:

• RTLinux and
• L4RTL [tu-dresden.de], a reimplementation of the RTLinux API on top of Fiasco [tu-dresden.de] (a real-time L4 [tu-dresden.de]-compatible microkernel) and L4Linux [tu-dresden.de]. In comparison to RTLinux, L4RTL sports address spaces for real-time tasks.

The simulated worst-case load was a combination of a heavy time-sharing load and a cache flooder.

On a 800-MHz Pentium III, the worst-case latency for RTLinux was 68 s. For L4RTL, it was 85 s.

Note that 68 s is considerably higher than what other sources quote as RTLinux's worst-case delay (in this thread, someone said 30--50 s). We believe that other researchers forget to take into account caching effects.

Anyway, it looks like both systems would be adequate for your application.