Real-Time Linux Experiences? 20
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."
Doing it the easy way... (Score:1, Offtopic)
These are commonly used in digital video production and are how most film -> digital transfers are performed today.
Re:Doing it the easy way... (Score:2)
One can only guess as to the use of the system. And seeing as how most of the current realtime applications are in the content industries (audio and video) and seeing as how audio is not likely to cause timing problems with current technology, it is only a guess...
There seems to be an immediate assumption here that it should be fixed in software (OS)
That having been said, the poster should have defined their goal more effectively to get an accurate response...
hmm? (Score:1, Insightful)
It sounds like it would be a bit of a heavyweight kernel for your needs.
experiences with pre-emptive kernel (Score:2, Informative)
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 (Score:1, Informative)
The Real-time Linux Software Quick Reference Guide (Score:2, Informative)
These guys might be able to help you (Score:3, Informative)
RT Linux - good if you only talk to hardware (Score:3, Informative)
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]
I dunno but... (Score:1)
Look at Timesys (Score:3, Insightful)
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.
Clarification (Score:2, Informative)
RT Linux (Score:1, Informative)
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
QNX if realtime UNIX is OK (not Linux) (Score:3, Informative)
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 (Score:2, Informative)
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.
Dedicate a few micro controllers (Score:2)
A trick to help keep a bunch of micro controllers running along with the same timing is to use a clock generator chip rather than give each micro controller it's own crystal. You feed the output from it to all the micro controllers as their clock input. Then they all run lock step with each other. If they have a separate timer input that also can be fed from a shared clock. An interupt input can also be used to syncronize all the micro controllers.
On your Linux, strip out as many of they system programs as you can. Many services are started that you just won't need, and they will compete for valuable CPU time.