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
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...
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?
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's unfortunate - I cooked mine a while back.
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.