Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Real-Time Linux Experiences?

Cliff posted more than 12 years ago | from the hardware-heaven-or-hardware-hell dept.

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

Sorry! There are no comments related to the filter you selected.

Don't kid yourself (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3430521)

Linux is far too buggy to be called anything but PartTime.

PartTime linux is fucking tits, dude. I work 20 hours per week, but get paid for 40.

First post! (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3430523)


mportant Stuff:
Please try to keep posts on topic.
Try to reply to other people comments instead of starting new threads.
Read other people's messages before posting your own to avoid simply duplicating what has already been said.
Use a clear subject that describes what your message is about.
Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)

Problems regarding accounts or comment posting should be sent to CowboyNeal.

Ask Slashdot should be renamed to (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3430642)

Do My (Home)Work For Me Slashdot


Do A Google Search For Me Slashdot

thank you

Doing it the easy way... (1, Offtopic)

OneFix (18661) | more than 12 years ago | (#3431049)

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.

Re:Doing it the easy way... (0)

Anonymous Coward | more than 12 years ago | (#3431295)

HUH? Who sais he wants to capture video data?

Re:Doing it the easy way... (2)

OneFix (18661) | more than 12 years ago | (#3431717)

Because there was no exact mention of the use of what the system was being used for...

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) ... this would be even more flawed than my assumption that it might be used for video...

That having been said, the poster should have defined their goal more effectively to get an accurate response...

hmm? (1, Insightful)

Anonymous Coward | more than 12 years ago | (#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.

Linux on VME (0)

Anonymous Coward | more than 12 years ago | (#3431450)

check []

experiences with pre-emptive kernel (2, Informative)

repoleved (569427) | more than 12 years ago | (#3431523)

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!


What some people think of Real Time Linux (1, Informative)

repoleved (569427) | more than 12 years ago | (#3431544)

This web site might be helpful. Report on the 2nd Real-Time Linux Workshop [] .

These guys might be able to help you (3, Informative)

repoleved (569427) | more than 12 years ago | (#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. []

RT Linux - good if you only talk to hardware (3, Informative)

motyl (4452) | more than 12 years ago | (#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 dunno but... (1)

xinu (64069) | more than 12 years ago | (#3431635)

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 (3, Insightful)

nadador (3747) | more than 12 years ago | (#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 (2, Informative)

fidget42 (538823) | more than 12 years ago | (#3433187)

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 (1, Informative)

Anonymous Coward | more than 12 years ago | (#3433680)

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.

QNX if realtime UNIX is OK (not Linux) (3, Informative)

andaru (535590) | more than 12 years ago | (#3433691)

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.

Worst-case interrupt latencies - RTLinux and L4RTL (2, Informative)

Read The Fine Manual (27464) | more than 12 years ago | (#3434743)

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.

Dedicate a few micro controllers (2)

Bryan Andersen (16514) | more than 12 years ago | (#3442960)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?