Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Kernel Goes Real-Time

Posted by ryuzaki0 on from the just-this-instant dept.

Several readers wrote to alert us to the inclusion of real-time features in the mainline Linux kernel starting with version 2.6.18. (Linus Torvalds had announced 2.6.18 on September 19.) Basic real-time support is now mainline. This will ease the job of developers of embedded Linux applications, who for years have been maintaining real-time patch sets outside of the mainline kernel. The announcement was made by TimeSys Corp., a provider of developer services. Much of the work was done by Thomas Gleixner at TimeSys and Ingo Molnar at Red Hat.

14 of 156 comments (clear)

  1. What about media? by stonedyak · · Score: 4, Interesting

    The article only talks about these new patches from the embedded devices point of view. So can anyone tell me if these new features would be useful for improving the responsiveness of media applications in Linux? I'm talking about video/audio playback, as well as authoring and recording.

    What other benefits would the desktop see from this?

    1. Re:What about media? by iotaborg · · Score: 3, Interesting

      The desktop probably won't see much from having a realtime kernel. A RTOS is great for integrating certain types of hardware, such as data acquisition systems, which can be time dependent. We use RTAI Linux at the lab for time-accurate data acquisition and control system in robotic applications. Most 'desktop' processes do not really depend on time; video and audio playback do, though without a RTOS video/audio play just fine. I do not believe you need kHz-MHz resolution for any desktop application for timing.

    2. Re:What about media? by fossa · · Score: 4, Interesting

      But desktop users, or at least me, don't care about doing things "fast". I care about things feeling fast. I care about latency. So, do these patches help the audio on my computer not skip when I move a window? I've tried the premptive kernel patches in the past with no noticeable difference. How are these patches similar, different, or complimentary to Ingo Molnar's (whose patches are mentioned in the article). Thanks.

    3. Re:What about media? by novus+ordo · · Score: 4, Interesting

      You are right, to a certain extent, but take audio/video work as an example. If I am using my computer as a synthesizer, I want to be able to hear the keys as they are being pressed, not 0.5-2 sec later. Even if the mixing part would take longer than the time I press my next key, the kernel should process that key anyway. Music is a weird thing.. a couple of milliseconds difference is enough to change the perception of a note. So in this case, it will 'seem' faster, even though it will have less throughput(context switches the mixing process out even though it has the mixing data in the cache which conveniently gets invalidated, swapped, etc.) I guess it gives certain applications the super-duper dependent on time factor that would otherwise be overlooked in the ways kernel measures "fast."

      --
      "You're everywhere. You're omnivorous."
    4. Re:What about media? by bazald · · Score: 3, Interesting

      While you are right, you seem to have missed his point entirely. One of the biggest applications of real-time scheduling for normal users (rather than pilots and nuclear plant controllers) *is* media. Pick up a text book on operating systems, and scheduling of media applications (audio, video, ...) is practically the first thing they get to.

      I for one believe that it could be immensely useful for Linux to provide the option of switching to a real time scheduler when starting a video playing - and for it to be able to tell you that there is no chance it will be able to run certain videos (HD for example) on older hardware.

      --
      Insert self-referential sig here.
    5. Re:What about media? by javilon · · Score: 3, Interesting

      For a long time, people using JACK (a low-latency audio server, written for POSIX conformant operating systems such as GNU/Linux and Apple's OS X) have been using real time linux patches to achieve better results. So for this kind of pro audio users, using Linux workstations (not embedded linux) it is quite nice to have included in the official kernel.

      --


      When his defense asked, "Which computer has Jon Johansen trespassed upon?" the answer was: "His own."
    6. Re:What about media? by glarbl_blarbl · · Score: 3, Interesting
      Music is a weird thing.. a couple of milliseconds difference is enough to change the perception of a note.
      Actually, the human ear is capable of detecting two discrete notes if they are separated by at least 30 milliseconds. If you set your digital delay to anything shorter than that, it won't sound like an echo - it will sound like the delayed signal is part of the original signal. Your example of a synth producing a note half a second after you hit a key is spot-on though, you'll notice that and be pretty annoyed if you're trying to do an overdub.

      http://ccrma.stanford.edu/planetccrma/software/ has offered a real-time kernel for as long as the project has been around, for the above reasons - and if you're trying to record 8 tracks of audio at 24b/96kHz you'll quickly realize that the kernel has to be able to handle all of that data precisely, or your drum kit recording is going to sound awful.

      --
      I use friend/foe to signal strong [dis]agreement instead of mod points. What else are f/f good for?
    7. Re:What about media? by glarbl_blarbl · · Score: 2, Interesting

      I know what you mean, and IMO many times sensory limitations are generalized to the entire population while extraordinary indviduals who spend time training their senses will be able to exceed them. I had the benefit of learning from professionals in audio production in a collegiate setting, and the I bet most people can't hear the difference between DVD quality and CD quality, and most of the consumer gear doesn't help there... I guess it's splitting hairs, but audio professionals who truly respect their craft will always strive to present the musicians' intent in the most transparent manner possible. I've always thought that breaking rules didn't mean much until I knew what they were.

      --
      I use friend/foe to signal strong [dis]agreement instead of mod points. What else are f/f good for?
    8. Re:What about media? by Pseudonym · · Score: 2, Interesting

      Real-time is all this and more.

      Getting tasks to complete on time is actually not something that an operating system can guarantee: you can simply lie about how long your job will take. (But, like your compiler, if you lie to your operating system, it will get its revenge.) Or you can design your hardware so that it swamps the system with so many interrupts that it can't service any user tasks. This kind of problem is a property of the system as a whole, and the best that the kernel can do is guarantee that if you play by the rules, it will too.

      Latency (be it interrupt delivery, signal delivery, context switch or whatever) is something that the kernel can guarantee for the most part, but even then, in an OS like Linux, where hardware drivers are part of the kernel, you also rely on those drivers to play nice. This means, for example, that it must not disable interrupt delivery around a loop.

      The other main things you need are things like the ability to fix data in memory (which Linux has had for a while), fixed-priority tasks and the ability for a task not to be preempted by a task of the same priority.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    9. Re:What about media? by Anonymous Coward · · Score: 1, Interesting
      Yeah, like the way Amarok "locked up" my computer for several hours yesterday. All I did was tell it to rescan the collection, and first the KDE desktop stopped working (clock wouldn't update the time, can't switch desktops, and stuff like that) then everything running from X stopped listening to the mouse and keyboard events. It took 30 minutes to ssh in from the LAN here, and when I accomplished that feat I couldn't do anything. Later on even ssh stopped working: it would accept a connection then immediately close it.

      Eventually my computer came back to me, but not after trying to kill the amarok collection scanner a few times.

      As far as I can see, the problems are several - when amarok starts scanning it does something nasty to KDE and doesn't stop it until the scanning is finished. Secondly, when scanning an AAC file, it seems to loop reading the same data from disk forever. Thirdly when scanning files, the disk drives are somehow monopolised by the scanner, so it's impossible for anything else to read the disk in a timely manner. That causes processes to run slowly, and loadavg builds up (due to cron, incoming server connections, and stuff). When loadavg gets high it's possible to SSH in but it takes many minutes and anything which requires disk I/O appears to hang. When loadavg gets very high, sshd detects this and drops connections (or maybe it's tcp_wrappers doing it).

      Applications should not be able to monopolise the computer to the extent that everything else just freezes. If it's a problem with the disk I/O I'd like to see what reconfiguration of the hardware will fix it - this is just two SATA drives on the inbuilt SATA adapter, in a RAID-1 array.

  2. This has got to be a good thing! by ztransform · · Score: 1, Interesting

    Many arguments are out there for and against Linux as a real-time embedded operating system. But with embedded processors getting more powerful and there is growing popularity with the Linux kernel anything that makes the job of an embedded developer easier (and standardised) is a good thing.

  3. It's progress, but not everything you need yet by Animats · · Score: 3, Interesting

    Linux has made major progress in the real-time area. But it still doesn't have everything needed.

    Many drivers are still doing too much work at interrupt level. There are drivers that have been made safe for real time at the millisecond level, but that's not universal. Load a driver with long interrupt lockouts and your system isn't "real time" any more. This is the biggest problem in practice. There are too many drivers still around with long interrupt lockouts.

    The Linux CPU dispatcher is now more real time oriented. (Finally!)

    Interprocess communication in Linux is still kind of lame by real-time OS standards. The tight interaction between CPU dispatching and messaging still isn't there, although it's getting better. Interestingly, it's there in Minix 3, and of course, that's been in QNX for years. For simple real-time apps, though, this may not be an issue. Generally, though, if you find the need to use shared memory between processes, it's because your OS's messaging lacks something.

    While Linux has been getting down to millisecond level response, QNX has been moving towards microsecond level response. The goal moves. However, millisecond response is good enough for most applications. What really matters in real-time, though, is worst-case response, not average. Benchmarks for real time OSs put a load on the system and measure how fast it responds to a few million interrupt requests. The number people look at is the longest response time.

    Despite this, Linux is probably now good enough for most real-time applications that can tolerate a big kernel.

  4. Bad for windows embedded by Anonymous Coward · · Score: 3, Interesting

    I was at the MEDC 2006 and one of the presentations was about how Linux was comparing to Windows Embedded.

    We got bunch of benchmarks showing how much more consistent the kernel response time were from Windows CE (custom Kernel) versus the Linux kernel, and how -on average- the Windows kernel had shorter response time. Some people in the audience asked (more than once) if they had benchmark from the Linux kernel with the real-time patches applied ... and the answer was they were benchmarking a 'for desktop' Linux kernel versus a 'for real-time' Windows Kernel. I was expecting M$ to put biased numbers but I could not stand it and left the room after 10 minutes.

    So the great thing about this announcement is that next year they won't be able to pull this off. Honestly I would not be surprised to see them use a 2.4 kernel, or show us how the stock Desktop kernel with a crap-load of unnecessary modules take so much more resources than the optimized Windows kernel.

    (sorry to post Anonymously, I guess I'm a Coward)
  5. glibc support? by Ingo+Molnar · · Score: 2, Interesting

    I have a question about the new mutex features: what glibc version is required to use this stuff? do I need other user space libraries?

    The latest upstream glibc version (2.5) has it:

    * Support for priority inheritance mutexes added by Jakub Jelinek and Ulrich Drepper.
    * Support for priority protected mutexes added by Jakub Jelinek.

    (See: http://sources.redhat.com/ml/libc-alpha/2006-09/ms g00065.html )

    No other userspace library is needed.