Slashdot Mirror
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!"
beos did not handle media well because of low latencies, it handled media well because of thoughtful media system design. beos actually has poor latencies and response times in a number of areas, it just accelled at scheduling and prioritisation
Don't hope you'll get this on your desktop anytime soon. This is RTLinux. Know what RT meants? Real-Time. That's a system in which you can guarantee the responsiveness.
But there's a catch: at development, you control all aspects (hardware and software) of that system. If just one component fails real-time requirements, you card castle crumbles.
In a desktop system, you can't control all aspects. That video card you just bought just added a little latency to your system, and it's not realtime. What is that program?
Never heard of it, but it fails RT requirement.
So, this is cool... but in the embedded systems field. Don't start comparing it to Windows XP and thinking you'll get it on a desktop Linux.
Misleading titles? Inflammatory blurbs? Keep in mind that Slashdot is a tabloid.
Exactly - almost all of the large movie houses use Linux for their rendering pipelines (see http://linuxmovies.movieeditor.com/software/index. html for more) and there is a LONG list of software available for pretty much every task you could ever want regarding creating / editing / processing video on Linux.
;}
Many of these tools are easily commercial quality and/or created by commercial companies for use on linux - and many of them are 'linux-only' which blows the 'not for linux' argument out of the water.
ignorance is bliss
Gekido's Lair
To me the numbers announced are on par with hard real-time constraints
One would hope so, from a hard real-time OS.
In any case, hard real-time does not mean "really low latency." It means "failure to meet latency guarantee is fatal." You can't necessarily make a soft real-time system hard real-time just by speeding it up, particularly if there are unbounded waits involved.
A better and more thorough explanation.
It says 5 microseconds, while the clock period is around 500 ps. That's 10,000 cycles, not 10 million.
Opus: the Swiss army knife of audio codec
Getting 5us interrupt latencies is not a difficult feat for an RTOS.
Indeed. One year ago, I participated in the installation of a High Energy Physics (HEP) experiment. We were using PowerPC 604 CPUs running VxWorks (the commercial "industry standard" RTOS).
On that configuration, I was getting interrupt latencies always under 12 us (3 us average), and that was on a 300 Mhz CPU ! 5 us is hardly impressive on the kind of systems they are using.
However, what would be interesting would be to know how the system behaves under load. RTLinux has been known in the past to crumble when heavily loaded by low priority tasks. It might have gone better recently.
Note that RTLinux is not the only Real-time Linux implementation. There's also RTAI released under LGPL.
Probably mostly true, but not entirely. Consider the case when you're using a computer in a recording studio to record a bunch of musicians. In the old days, they used multitrack tape machines which could be configured so that each track could be individually set to record or to play back. Might then record a drum kit on 5 out of 16 tracks, and then come back and have someone else (the bass player, then instrumentalists, then singers) come and lay down tracks on top of that.
These days, tape is effectively dead, and people do this all with computers. And not, generally, with specialized kickass embedded computers, but with Windows machines or Macs.
So, what is the relevance of all this to latency? Well, when you are doing multitrack recording on a computer, you are doing something fairly unique: you are recording a track, but at the same time you are playing back the tracks that have already been recorded and the signal you are getting from the instrument or vocalist that you're recording right now. So, the (let's say) guitar player you're recording hears the drum and bass tracks that have been recorded as well as his own guitar, and all of this is coming through the computer.
Now, one little quirk about musicians (and I'm sure you'll understand once you think about it) is that they really hate hearing themselves in their headphones if what they're hearing is coming in 100 ms later than when they're making the sound. This tends to throw them off, because rhythm is an important part of music.
As a result, guys with workstations that are used for recording are to an extent after the lowest latency they can get their hands on. The only way to achieve this is with a minimum amount of buffering of the audio data and an OS that can handle servicing interrupts for the device driver quickly AND scheduling the audio software to run in time. Well, either that or a minimum amount of buffering and ridiculously over-specced computer so that the CPU is just so fast that it doesn't matter as much if the operating system sucks.
So, a system like this could be really great for a recording studio. That is, if Linux had pro-quality recording software and supported device drivers from pro-grade A/D and D/A converter manufacturers. (I'm not talking about your average Soundblaster Live here -- I'm talking about things that can around 16 channels of 24-bit, 192 kHz, both in and out, simultaneously. Hardware like that is fairly uncommon, and professional recording guys are not going to use a third-party driver -- they want something with support from the manufacturer of the hardware, because if the system dies in the middle of a session, they may have lost the chance to capture a performance that can never be reproduced.
My point (other than that Linux has a long way to go on the application software side of things for pro audio recording) is that latency can be a hugely important thing for audio -- if it's audio that involves live musicians or an audience in any way.
that "real time = real fast."
Often, nothing could be further from the truth.
What's missed here is a Real Time OS is being compared to Windows XP. Windows anything is not a real time OS. It keeps getting pushed into real time use, simply because it is there, but it is not the best tool for the job. Having an OS respond in real time to interupts is like having a mouse that doesn't freeze for several seconds at a time on a busy system. (if you run Windows, you know what I'm talking about.) Using Windows in a real time environment such as video encoding, or such almost always produces the ocasional jump or glitch because Windows is not a real time OS. Interupts get ignored during such things as a disk access.
The truth shall set you free!
Give Ingo Molnar's RT preemption patches or the I-Pipe approach a look some day. "1-2 years" ago can be a long, long time when it comes to Linux... :)
quidquid latine dictum sit altum videtur.
Okay, I'm going to clear this up near the top of the article.
RTLinux is a *Real Time Operating System*, a tiny kernel that runs the Linux kernel. It has a rather sexy interfact that allows you to write the non-RT code that interacts with it in the regular, Linux way. You also don't need to hassle with Wind River salesmen to use it. This makes it good.
There seems to be a significant misperception here as to what an RTOS is, and the extremely misleading article summary makes it worse.
An RTOS is an extremely specific tool designed to allow someone to write code with very harsh restrictions on it with very low latency. This is almost always used for control applications (telling servos when to fire accurately). You can't "run Quake in RTLinux" and just get more accurate times -- code running as real-time in RTLinux can do very little besides memory manipulation, basic computation, and some extremely limited I/O. RTOSes are powerful tools for solving a very limited set of problems which very few people on Slashdot have.
RTLinux lets you write very simple, limited code that runs in a real-time mode, and run it on the same machine as regular Linux applications. And communicate with them. That's it. Doesn't do anything to improve the regular ol' Linux applications.
RTOSes give very low latency to the code they run -- something happens, code to handle it gets fired off very quickly. Microsecond latency (*not* millisecond) is completely overkill for the kind of general-purpose video or whatever work that people here are thinking of, unless you're trying to build some sort of specialized embedded system that does something to a real-time feed -- and your hardware's going to be very specially designed for this.
There's a good reason that we don't use RTOSes in day-to-day work. They have bad throughput, and you can't *do* very much with them in real-time. They're good if you specifically have a latency constraint from the time one sensor triggers to the time I/O goes out to another device. They aren't going to avoid audio dropouts on your GNOME desktop. Real-time is a *bad thing* from most people's standpoint -- oh, and they're really easy to accidentally hang.
If you want something to get excited about for general purpose use, look at the preempt patches for 2.6. 2.6 Linux has better latency than Windows XP (2.4 had worse). This is not RTLinux, this is regular-ol-Linux-which-can-run-Quake. My understanding is that ALSA and JACK represent improvements in the general-purpose latency area.
Unless you are designing application logic for robotic control systems, or are interfacing with PLCs, RTLinux really doesn't benefit you (okay, I'm sure there's someone out there that has a different application, but Joe Hacker with his Gentoo box doesn't benefit directly from this).
Every time realtime systems come up on Slashdot, misperceptions of 'em seem to get worse.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
If you *do* want to do high priority stuff on your box, both (regular) Linux and (regular Windows, without getting RTX or any Windows RTLinux equivalents) have "realtime" scheduling options (see the "Realtime" option in Windows Task Manager, or the sched_setscheduler(2) man page under Linux). These aren't actually hard realtime, but give you all the fun of being able to lock up your box (as per realtime systems do) without losing the ability to still run general-purpose applications. You won't get single-digit microsecond latency, but you won't be worrying about audio dropout either, and you get to do fun things like use general-purpose libraries, use sockets, use virtual memory and all the other stuff that you can't do in real-time code under RTLinux.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
Howdy. I'm the author of the LinuxDevices.com article on RTLinux, and I have also played around a bit with demudi, the debian music distribution. Demudi (and the red hat remudi anodyne) use a 2.4 kernel patched to reduce application latency. You run all the sound aps as the root user in demudi, and jackd keeps track of real-time performance. Here's a summary of my experience.
Local songwriter wrote an album of songs, bought a Walmart PC for $300 powered by a Celery 1800 processor. He bootlegged a copy of cubase from a pal. Couldn't figure out how to use it. He then downloaded a cheap copy of cool edit pro. Recorded a dozen songs -- they sounded awful. He comes to me for help.
We install Demudi, stick in an M-Audio Delta 440 card, a $200 sound card with hardware mixer/monitor and 1/4-inch TRS 4-in/4-out breakout box. We record six songs in three days, each with 10 tracks or so, even though we had only a tiny amount of experience using ardour. We master everything at 24/96, and downsample to cd quality for the final. It sounds great!
The trickiest part is actually the downsampling, because jackd shuts the whole thing down when the CPU fails to deliver on real-time guarantees. This becomes a royal pain. We resort to shutting down all unneeded linux services in order to get the final mixes downsampled. It's a pain, but it finally works.
And the results are good. A professional sound engineer with 20 years experience listens to the results, and comments, "How many tracks were you doing at a time? Sixteen on this song? It's remarkable, because the sound doesn't get brittle. Usually, with that many tracks, things go brittle at a certain point."
Despite the fact that demudi has a real-time kernel, there *is* perceivable latency in the monitors when using software monitoring, though. Luckily, Alsa does support RME cards, and M-Audio cards -- pretty much. With M-audio cards, you have to use the console alsamixer to get to all the features of the card. But it can be done.
I don't think RTLinux would be used for real-time audio, though, since you need the Linux apps to be real-time, not just the hardware interrupts. But I don't know.
I do think the work Ingo and MontaVista are doing with native real-time Linux will have a huge impact on the A/V and effects industries.
This isn't that impressive for RTLinux, which is really a scheme for loading applications as loadable kernel modules running without memory protection. RTLinux is an obsolete approach; the more recent Linux variants from Lynuxworks and Montevista have a much cleaner approach, based on the low-latency fixes in the 2.6 kernel.