Slashdot Mirror
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."
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.
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
I am currently using (and used to work for) Timesys.
They have a bunch of BSPs for PowerPC boards. I don't know about VME support, mostly cause I'm working on something on a PCI bus right now.
Couple of cool things about the Timesys Linux kernel:
(1) Fully preemptible kernel (2.4 series, and not the Montavista-derived one that its in 2.5);
(2) Schedulable interrupt handlers and bottom halves (like IRQ7 is a separate thread);
(3) low worst case interrupt latency (70us on a 700MHz Pentium is what the data sheet says, which isn't as good as say 15us on a traditional RTOS, but that 70us is for a real Linux interrupt or process, not one under RTAI or another real time kernel);
(4) CPU and network reservations - so your real-time processes can request that, for example, 3 out of every 18 milliseconds be reserved on the CPU so that its guarenteed to meet its deadline, etc.
They also have a bunch of simulation and modeling tools so you can do things like RMA, etc., on more complicated systems, etc.
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
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.
Why is Grand Theft Auto a much more serious crime than Reckless Driving?