RTLinux Boasts Single-Digit uSec Responsiveness

An anonymous reader writes "A Linux implementation delivering single-digit microsecond responsiveness on 64-bit dual-core AMD Opteron processors is being demonstrated at the Embedded Systems Conference in Boston this week. From the article: "According to FSMLabs, an AMD Opteron 265 dual-core system running RTLinux can deliver guaranteed interrupt latencies of no more than five microseconds, with scheduling jitter of no more than eight microseconds, even with Linux under a heavy load." Heck, with numbers like that it seems like Linux could run circles around XP Pro for audio/video apps such as streaming, recording, and playback!"

Comments

Anything else think...

[gorim]

That its ridiculous that RTLinux needs to run on a dual-core AMD Opteron in order to achieve those latencies ? How many RTOS *can't* do that ? How many embedded systems will be created out of dual-core AMD Opterons, considered that they are usually made out of bottom dollar hardwares ?

Re:Anything else think...

[slashdot.org]

That its ridiculous that RTLinux needs to run on a dual-core AMD Opteron in order to achieve those latencies ?

Yes. I think for anyone that has done embedded systems for a while that's laughable.

Before I start on my rant I will say that (a) the last time I've looked into Linux as a potential embedded OS has been a while (1-2 years) and (b) a fair amount of elitism can't be denied when it comes to talking about RTOSs.

Having said that, I never understood why people are so hot on making Linux an embedded RTOS. The kernel is NOT designed to be an RTOS. The distributions/tools are not designed for embedded.

Last time I looked at RTLinux, it would have been more accurate to call it a very small RTOS kernel that ran Linux as a sub-process. You needed to write/port your own drivers for devices that needed real-time response. The Linux kernel itself was not real-time.

The last version of the Linux kernel itself that I looked at was not designed to be re-entrant/pre-empted in a way that's required for a true RTOS. However, the multi-processor "#ifdefs" seemed to make it possible to create a kernel which locked at a much "lower" level. I think Robert Love's patches took advantage of that and from what I understand those are now incorporated into the main source tree (but I'm by no means a regular lkml reader), which IMHO was a more promising path to take. Although I still don't think it's making Linux a viable RTOS...

Re:BeOS

[DRobson]

BeOS isnt a realtime operating system, that is it doesnt make any hard gaurantees about whether something will occur at a given time. That said it does go to some length to schedule time critical processes appropriately hence where it got its reputation for responsiveness; Used some weird voodoo magic in the scheduler I guess...

And yes, I'm a huge BeOS fan :)

I do

[Sycraft-fu]

We solve this in a number of ways. For most live stuff the answer is simple: Don't use a computer. You can crow about a realtime system all you want, I'll take a video switcher any day for live video please and thanks.

For audio recording, the software takes care of this. The latencies are known to the software (if it's worth a shit) quite precisely. I tool aorund with MIDI and frequently I'll use a combination of hardware and software synths. The software ones are rendered directly to a wav file, the hardware one is recorded digitally via S/PDIF. Now normally I run my setup with pretty conservative buffering, there's about 50ms of input latency, which is an extremely noticable amount of latency. Yet, when all is saind and done and the tracks are loaded up in multi-track, you hear no latency. Why? Well the software knows about the input latency and corrects for it.

The importace of low latency comes in to play when you are doing sound on sound, musicians monitoring themselves via the software. Then it needs to be low, or they'll get screwed up. No problem, a good audio setup can get 5ms or less of latency. If you really wnt low latency, again screw the computer. Monitor via your mixer, just have the computer record.

Also I'm not so sure a RTOS is what you want. Remember RTOS is all about gaurenteeing time slices to all devices. It basically says you will get a time slice of at least x ms a minimum of every y ms. Ok, great, but what if your critical device needs more time? What if your sound input needs 2x ms to service it or needs it every y/2 ms? A non-realtime system can put off other stuff to do that, a RTOS can't since the whole design is reliable scheduling.

Re:Er?

[hyc]

Of course, M68000-based Ataris and Amigas have been excellent for this type of task for over two decades. x86 PCs and Macs have always had inferior clock stability, regardless of the OS on top. I suppose part of that may be because M68K hardware is more suited to embedded systems anyway, and part of that may be because the designers of those Atari and Amiga systems came from the arcade game culture, which is a ridiculously demanding programming environment to begin with, where responsiveness makes or breaks the game. (If the game is unresponsive, it gets unpopular fast, loses money fast...) I suppose that's why M68xx and Coldfire chips are still so popular for embedded systems.