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."

Comments

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.

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

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.