Slashdot Mirror

← Back to Stories (view on slashdot.org)

RTLinux Boasts Single-Digit uSec Responsiveness

Posted by ScuttleMonkey on from the speedy-gonzales-makes-his-linux-debut dept.

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!"

10 of 362 comments (clear)

  1. BeOS by VVrath · · Score: 3, Interesting

    Anyone know how this compares with BeOS? I was under the impression that (certainly for it's time) BeOS was the mutt's nuts for audio/video work.

    1. Re:BeOS by DRobson · · Score: 4, Interesting
      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 :)

  2. News flash: by Anonymous Coward · · Score: 3, Interesting

    Apparently it is. Despite all the latency patches for the 2.6 linux kernel "(X) Preemptible Kernel (Low-Latency Desktop)", "[*] Preempt The Big Kernel Lock", and that Timer frequency thing, linux handles A&V like CRAP. None of the Debian/RH machines I use at work are any better than my home (Gentoo) machine, either.

    I love linux, but Windows handles A/V like a champ (with the exception of, perhaps, editing the two, bug I have no experience in this area...) And I'm not going to go out and buy a dual core opteron just so my linux box can play video and sound without stuttering under a load.

    Try playing WoW on a dual head setup with video playing on one screen and the game in the other. Windows handles it amazing well, while linux chokes horribly. This can be somewhat alleviated by reniceing the process, but that kind of defeats the purpose of the whole "low latency desktop" thing, doesn't it?

    IMHO, audio is perhaps the one place where choice hasn't helped linux.

  3. Anything else think... by gorim · · Score: 4, Interesting

    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 ?

    1. Re:Anything else think... by slashdot.org · · Score: 4, Interesting

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

  4. Strange: I can't find the source by Rogerborg · · Score: 3, Interesting
    At FSMlabs. There's an RTLinuxFree, but why settle for the crippled version when the source for RTLinuxPro should be available.

    I've emailed them asking them what they've done to satisfy section 3 of the GPL version 2. I await their reply with interest.

    --
    If you were blocking sigs, you wouldn't have to read this.
  5. I do by Sycraft-fu · · Score: 4, Interesting

    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.

  6. Re:Er? by hyc · · Score: 4, Interesting

    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.

    --
    -- *My* journal is more interesting than *yours*...
  7. Re:Er? by donscarletti · · Score: 3, Interesting
    FWIW "codex" refers to an old style of manuscript with multiple pages bound together, an old style of book from the middle ages. The word you are looking for is "codec".

    http://en.wikipedia.org/wiki/Codec, http://en.wikipedia.org/wiki/Codex.

    I can't spell either, but I figured that straightening out the meanings might be interesting to some people.

    --
    When Argumentum ad Hominem falls short, try Argumentum ad Matrem
  8. Re:QNX by HermanAB · · Score: 3, Interesting

    QNQ, VxWorks, Nucleus etc.: A few hundred clock cycles ISR response time.

    --
    Oh well, what the hell...