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!"
First, it's on a desktop system with a desktop CPU running really fast. Getting 5us interrupt latencies is not a difficult feat for an RTOS. Yes, it may beat Windows XP's latencies, but on a desktop OS, latency isn't typically a big deal (does XP even claim to be realtime?).
Second, what are the limitations? How does RTLinux handle priority inversion? How does it stack up to something like OSE-RTOS or GreenHills? Just how preemptible are those ISRs?
And finally, what is the performance penalty? Just because you are servicing interrupts at lightning quick speed, it doesn't mean you get a boost in speed. It may mean you have to lower the priority of many system services.
I am skeptical of RTLinux's claims, though the numbers seem to be in order. Maybe it is just their actions in the past (FSMLabs) that has colored my opinion of them.
Jesus saved me from my past. He can save you as well.
Why would you need fast interrupt speed for multimedia? If anything, a real-time kernel would reduce efficiency for multimedia. You need raw CPU for that, not fast interrupts. RTLinux is for applications where you need the computer to react really fast, like in science experiments.
But this would assume that decent, feature rich apps for doing this actually exist and are stable on linux - which we all know is currently a pipe-dream...
Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
>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!"
To me the numbers announced are on par with hard real-time constraints, for which there are a lot more interesting and critical applications than a/v streaming, recording and playback!
How about anything the pure real-time kernels can do, such as running a car, plane, spaceship, etc ?
I'm not into audio/video stuff at all, but my girlfriend is, she's a graduate from one of the most prestigious 3D colleges in Europe, classmates are working with Pixar, Saab, BMW and so on in 3D modelling. And other courses in that college were orientated around pro video, pro audio and other stuff with cutting edge computer needs.
And all these people I chatted with, did not ever give as much of a crap about hardware. They use applications, they use Final cut Pro, or Maya, or PRman, or Logic Audio, or Cubase or Digital performer or whatever, they all have apps they like. But they aren't seeing the hardware as any kind of big deal. If they need something done faster they get a new PC.
Linux needs to get the applications before it can boast about the microsecond speed advantages.
According to the article, this OS is touted for its extremely fast responsiveness, presumably to any interrupts from external devices (since it is targeted at an embedded platform) etc. because of the way it 'reserves' the CPU for such activities.
This decreases latency (response time to some stimulus, in the most general definition) but does not increase the total throughput.
For embedded applications such as perhaps a data acquisition system that might want to sample one external circuit's output when another circuit sends a line high, this is perfect because the system can react extremely quickly and thus increase the accuracy of the data.
However, it is conceivable that because of processor reservation, you will lose some of the power available to you. Thus, you cannot say for sure that it can run circles around XP based on simply this feature...especially for a feature like encoding a video which doesn't depend much on interrupts.
There might be other reasons for why Linux is a better platform for streaming, playing, recording, or encoding video. But I doubt this is it. Real-time OS's are aimed at embedded applications, usually systems that combine both external hardware and software...
Am I the only one who thinks ScuttleMonkey's comment on this story is a bit...out of place? Why would you need one-digit microsecond scheduling jitter for multimedia applications?
For 'real' real-time applications, this is gold though, especially now that many more people realize Linux' potential in this area - heck, even the good folks over at Windriver have realized that now, and they used to laugh at us Linux folks.
If a train station is a place where a train stops, what's a workstation?
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!
Umm.. why compare a REAL TIME operating system to Windows?
Adobe Premiere Pro?
Apple Final Cut Pro?
Cakewalk/SONAR?
I won't see anything that compares to these, but I may have over looked.
Of course, it has little or no relevance to media and video processing, as those are related to throughput and bandwidth, not latency. Additionally, of course RTLinux does better -- as the name suggests, it's a real time OS. Normal Linux, Windows, OSX, etc. are not real time OSes, and such latencies are not necessary.
When you need a real time OS with ridiculously low latencies is when you have something mission critical. For example, a nuclear reaction being controlled. Say, interrupt 666 triggers when something goes horribly wrong, and if you enable a safety system within 10ms, nothing bad happens. It would be good to have a system that guarantees response in less than that time. That's the purpose of a real time OS like RTLinux. This is not appropriate, necessary, or indeed useful for desktop systems or workstations of any sort, or even servers.
5 us latency is good and all, but that is VERY fast hardware. A better measure would be using a system somewhat comparable to an advanced industrial controller, which is where RTLinux is meant to be used, IMHO. Something like a 667 MHz VIA processor board(no affiliation) is rather high-end in that respect - rate it on such a system, and your numbers will actually mean something.
To those who compare this to XP - you've completely missed the mark. XP is not, will never be, and has never been claimed to be realtime. There really is no comparable offering from Microsoft at the moment, with Windows CE coming closest in terms of realtime capability. I doubt that 5 us is within reach on ANY hardware with WinCE, though.
Black holes are where God divided by zero
that "real time = real fast."
;)
Often, nothing could be further from the truth.
I wonder why this seems to escape Slashdot article authors.
Wait... nevermind
+++ATH0
>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!"
Yeah, but how feasible is it to run RTLinux just to watch DVDs?
But usecond resolution would be usefull for higher-frequency data processing and control.
i really hate when people confuse network latency with CPU latency or driver latency or poor software running on the application layer.
There are high-end commercial tools that are available for a lot of money, and some major production houses use them. However here's one for you: Find a Linux alternative to Final Cut. Basically you need a solution for around $1300 dollars that is a full featured SD/HD editor, effects, DVD authoring and so on. Oh and it also needs to be easy to use (Final Cut is extremely user friendly).
Now on the Windows side, you can get software that plays in the same league. It's questionable if it's as good as Final Cut, but it's in the same Ballpark. Sony Vegas would be one, the Adobe Video Suite would be another. Basically, if you are an individual or small orginization looking at doing smaller budget work, there are reasonably priced solutions to meet your needs. They are professional, powerful, and easy to use (I particularly like Vegas). They are also flexable in that you can do DV work, streaming media, HD (consumer and pro) and so on. You can fully produce a web demo in RealMedia in the same program you make a show for broadcast.
Now look at those Linux utilities listed. Some of them are just plain wrong (Fusion for example lists only Windows 2000 and XP as supported OSes, not Linux). Most of the ones that are real are in the "if you have to ask it's too expensive category" as in they don't even list prices on the web, it's a "contact us for a quote" situation, in fact I couldn't find prices for any commercial editor. One of the few programs I actually could find a price on was Shake (which is Apple and thus also works on OS-X) and it's $3000 and it's JUST a compositor. Vegas and Final Cut and the like do compositing as well, admittedly not near to the level of Shake, but they do it well enough for most low level work.
Now as for the free software, well if there's good stuff out there, I've never seen it. The AV editing situation on Linux is abysmal last time I tried. Maybe I was just unlucky, maybe I've never been pointed to the right products, but even when I got stuff working, it was a distant second. I tried the Planet CCRMA Fedora image, which has everything you need all installed (it's designed to give you an AV workstation) and all configured, and I found that Vegas installed on vanilla Windows was much better.
So it seems that you can use Linux, when you go really high end, but then the OS isn't so much of a big deal. You are likely buying enterprise Linux (most of the stuff only provides support under things like RHEL) and thus paying for licensing anyhow, and the software cost is enough to dwarf the OS cost. Many times it's even turnkey solutions (meaning they provide the entire hardware/software package).
Great, but what about the rest of us? What if you work for a school and want to do online education videos? What if you are a band that wants to make low-budget music videos? What if you are a film student that wants to make indy digital videos?
It seems that Linux would be the way you'd want to go since the whole free thing, but it seems the tools available for it are the very least suited. They just don't match up to the commercial tools for Mac and Windows, and the commercial tools are things you might actually use later. If you go on to work broadcast TV, it's a good chance you may run into a Final Cut workstation. Even some Hollywood movies are being done in Final Cut these days. Not likely you are going to find a Cuisene station, to them it's worth the grand or two in software and OS licenses to have something that easier to use and more powerful. Please also note that it's the ONLY free video editor listed on the site you linked to.
So I guess when I have a choice between Vegas, which does multi-track audio and video editing, effects, titles, compositing (somewhat simple but not bad) motion tracking, audio effects, streaming input output, DV input/output, MPEG input/output, and so on for like $400-500 all in one easy to use package, or Cuisene which works only with DV and is hard to use, Ardour for sound which is a pain and lacks effects, probably something like POVray to render 3d effects since nothing built in and so on for free, I'll take Vegas. The $500 plus a $100 for Windows is worth it for the fact that I can just easily get shit done.
RTLinux is not a desktop distribution. It is designed for systems control. Like robots that build cars, small delays in response time could see welds done in the worng spot etc. This way with RTLinux, you can move robotic arms faster without fear that the OS will update too slowly to catch the data about where the arm is etc. It really has little to do with watching videos on WinXP. Most Linux distros IMO already do that better ;)
a) You should be able to do what you want with this, and possibly any, version of real time Linux. The real question is what what level of responsiveness do you need?
b) Get the make/model info for the card and see if there isn't already a driver for it. If there isn't, it may be possible to get a driver written, either by finding documentation on the card, or reverse engineering the DOS drivers. Any more of an answer is kind of moot because there isn't enough information in your post.
Could you use a different/newer/supported card for this experimental system?
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
For example, a nuclear reaction being controlled. Say, interrupt 666 triggers when something goes horribly wrong, and if you enable a safety system within 10ms, nothing bad happens. It would be good to have a system that guarantees response in less than that time.
Just wanted to comment that the requirement for real-timeness is usually a lot less spectacular then the good ole nuke example. It's usually more something like "interrupt 12 triggers when 14 out of 20 network receive buffers are full, and if you don't respond within 10 microseconds by freeing some of those up, the other 6 buffers are potentially going to be full and the network controller has no place to put incoming data, so it will drop anything coming in after that point".
> 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!"
/. and make "m$ suckz" and so-called "Funny" comments.
Heck, with brain like that it seems you could run circles around a tree without realizing you're not getting anywhere.
Just look at his piece-of-shit submission - the only interesting part is one that was copied from TFA and the rest is a "I'm a moron" type of comment that tells everyone how stupid and clueless the submitter (and the editor) is.
If had any brains and if he bothered to spend just 10 minutes to make a quality submission, he'd have read an article or two related to RT OS and he would:
a) compare RTLinux to published latency figures of some other (open or proprietary) soft- or hard-RT OS
b) would not make that idiotic Windows XP comment since it is completely irrelevant
c) would make a link to best of those reference articles that he reviewed prior to submitting the story
Being such, the article only does a good job in making tons of likely-minded folks gather at
The editor should have edited out the stupid Windows XP comment or replace it with something meaningful. Not having done that, he hasn't done his job and I can only pass to him same compliments that I had for the submitter.
Everyone, learn how to skip stupid submissions, it's a great way to save time not stupefy yourself.
The problem is that on certain days you can skip pretty much everything.
Yes, the submitter's jab at Windows XP is somewhat inflammatory and misguided, but so are the comments of all the self-proclaimed RT experts who always seem to come out of the woodwork at the first mention of "real-time."
The RT experts say "multimedia isn't real-time." Multimedia is absolutely real-time. If you miss a deadline for supplying the sound card with an output buffer, you get clicks and dropouts. If you miss a deadline for pulling input buffers, you lose recorded data. No, it won't launch a nuclear missile, but it is clearly a real-time operation.
The RT experts say "but multimedia doesn't need scheduling latencies that low." It's true that single digit usec latencies are beyond what most multimedia systems require, but single-digit msec responses would be extremely welcome. In fact, if you've ever followed JACK (JACK Audio Connection Kit) development, you'll discover a community of people who invest significant effort tuning their kernels and environment exactly so they can get these kinds of latencies. If you're dragging sliders on a mixer while playing back a multi-track recording, you care very much about latency. If you're using your computer as a real-time effects processor, you care very much about latency.
This is why the XP comment, while somewhat inflammatory, has some truth to it: the lower-latency your operating system, the more useful it is for these kinds of tasks. Who cares if it calls itself a "real-time" operating system or not -- what I care about it what's on my desk!
The RT experts say "no fair comparing RT Linux with Windows XP, a non-realtime system." I'm not sure why we take it as a given that this dichotomy must continue to exist. Why do we accept that general purpose operating systems can sit on an interrupt for an unbounded amount of time? If a high-priority interrupt comes in, I want it right now!
Computers are really fast these days, but latencies do not decrease in proportion to CPU speed. What good is my 20GHz Pentium VII if arbitrary drivers still grab locks for tens or hundreds of milliseconds?
Rehashing the same old lines isn't insightful, it's backward-looking. Yes, I know that "real-time is about guaranteed deadlines." But current CPUs are so fast they could probably render a mandelbrot set before they give me the CPU and I wouldn't notice. But as long as they're holding these locks, I'll never see the benefit.