Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
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:
  • hmm? (Score:1, Insightful)

    by Anonymous Coward on Monday April 29, 2002 @03:53PM (#3431129)
    What, specifically, do you need to use Linux for?

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

    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.

For God's sake, stop researching for a while and begin to think!

Working...