Become a fan of Slashdot on Facebook


Forgot your password?
Linux Software

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."
This discussion has been archived. No new comments can be posted.

Real-Time Linux Experiences?

Comments Filter:
  • Why worry about having the OS do it for you...why not look for a MPEG2 encoder card like the LinuxTV [] card. Or even some of the complete solutions that allow you to capture directly to a dedicated harddrive.

    These are commonly used in digital video production and are how most film -> digital transfers are performed today.
  • hmm? (Score:1, Insightful)

    by Anonymous Coward
    What, specifically, do you need to use Linux for?

    It sounds like it would be a bit of a heavyweight kernel for your needs.
  • 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!

  • This web site might be helpful. Report on the 2nd Real-Time Linux Workshop [].
  • by repoleved ( 569427 ) on Monday April 29, 2002 @04:45PM (#3431592)
    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. []
  • by motyl ( 4452 ) on Monday April 29, 2002 @04:49PM (#3431617)

    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'd use x86 Solaris (or even a Sparc since you refer to VME bus, not even the same but I assume you need a hardened system) in this particular case for Real Time Scheduling needs. It doesn't help yah with VME bus since or something along those lines. But in the long run much easier to configure and no patching or hacks, just a couple one liners to /etc/system. And it's a pretty cheap solution.
  • Look at Timesys (Score:3, Insightful)

    by nadador ( 3747 ) on Monday April 29, 2002 @04:53PM (#3431644)
    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.
  • Clarification (Score:2, Informative)

    by fidget42 ( 538823 )
    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 (Score:1, Informative)

    by 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.
  • by andaru ( 535590 ) <> on Monday April 29, 2002 @11:14PM (#3433691) Homepage
    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.

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

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

    • RTLinux and
    • L4RTL [], a reimplementation of the RTLinux API on top of Fiasco [] (a real-time L4 []-compatible microkernel) and L4Linux []. 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.

  • When I need guaranteed timing I dedicate a microcontroller. You can do your calculations on the linux box then send the result to the micro controller which then passes it on at the right time. Yes it is a bit of hardware, but many things can be done with quite simple hardware setups. On a robot of mine I have all the low level functions handled by dedicated micro controllers. They all talk to the host Linux system which isn't even a real time based system and everything gets done on time. All the high level decisions are done on programs run on the Linux host and then they tell the micro controllers what to do and when to do it. The micro controllers also feed information on events to the programs. The only thing I did special was memory lock the programs. Otherwise they are running under a stock 2.2 kernel from a Debian distribution.

    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.

"It takes all sorts of in & out-door schooling to get adapted to my kind of fooling" - R. Frost