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

[VVrath]

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.

Re:BeOS

[DRobson]

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 :)

For the love of Christ people, it's a RTOS

[typical]

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.

If you just want better latency

[typical]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Er?

[_Sharp'r_]

RTCore also supports zero-copy real-time networking on Ethernet and FireWire (1394) via the LNet extension. LNet enables hard real-time control of networked devices as well as facilitating the use of real-time networking to control data flow and perform fault recovery for enterprise applications.

With tools shipping to do this right now, this may actually make a nice impact in the feasibility of routers/fws/filters/LBs/etc... processing higher-level protocols at nearer wire speed.

Nice!

Re:Er?

[PsychicX]

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.

Everyone is convinced

[StarKruzr]

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 ;)

Re:Everyone is convinced

[Technician]

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.

WTF mods?

[SmittyTheBold]

It's not "funny," it's true [microsoft.com].

Re:Er?

[adrianmonk]

Of course, it has little or no relevance to media and video processing, as those are related to throughput and bandwidth, not latency.

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.

Re:Er?

[wulfhound]

I should just point out that these kind of ultra low latency designs for audio DSP essentially require an unbuffered, 1-sample audio signal graph. Which is likely to be horrifically inefficient on desktop CPUs compared to the 64-1024-sample buffered graphs in common use. Meaning you'll need 3x as fast a CPU to get the same track and plug-in counts as before.

Re:Er?

[hyc]

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.

Re:Er?

[Afrosheen]

Yeah and it needs to be mentioned that the Amiga and older (Falcon) Ataris were some of the first truly multi-tasking machines available for the desktop. By 'truly' multi-tasking I mean they had separate chips for each part of the system. They had a video chip, an audio chip, a drive controller chip, etc. and the OS just had to lay around and send commands to each one. This was way different than the IBM PCs at that time which were horribly limited in comparison. The way they worked was beneficial to musici

Re:Er?

[nerdyH]

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

Re:Er?

[slashdot.org]

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

Re:Er?

[CRC'99]

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

Re:Er?

[Korgan]

Not true. The videolan client meets that criteria exactly. It runs headless on Linux and pretty much anything else. Streaming that in various formats (including MP4, DivX and so on) is as simple as getting the codex.

If it doesn't exist already, it wouldn't be hard to write a streaming module for mplayer. Whether that be streamed to pipe, file or socket. It can already read most codecs and if you have a license for the WMP Win32 DLLs, it'll handle that too.

There are a lot of options for Linux.

Re:Er?

[strider44]

If it doesn't exist already, it wouldn't be hard to write a streaming module for mplayer. Whether that be streamed to pipe, file or socket. It can already read most codecs and if you have a license for the WMP Win32 DLLs, it'll handle that too.
mplayerplug-in

Re:Er?

[donscarletti]

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 [wikipedia.org], http://en.wikipedia.org/wiki/Codex [wikipedia.org].

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

Re:Er?

[at_slashdot]

"which we all know is currently a pipe-dream..."

To assume that all people know as little as you do it's a big fallacy.

Re:Er?

[abandonment]

Exactly - almost all of the large movie houses use Linux for their rendering pipelines (see http://linuxmovies.movieeditor.com/software/index. html [movieeditor.com] 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 ;}

Re:Er?

[abandonment]

http://linuxmovies.movieeditor.com/studio/index.ht ml [movieeditor.com]

a list of major motion picture studios and the movies that have been produced on linux.

but NOO, there are no tools for video on linux ;}

Well I suppose it should be clarified

[Sycraft-fu]

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.

Heard of VLC player

[anandsr]

It is the best player available for windows. It is the only player that can play crippled DVDs and VCDs without crashing and it is the only one that can handle partially downloaded files. It also handles a very large formats as opposed to a very small subset provided by the proprietory vendors.

I am sure we will get other apps soon. Its not like the Movie industry is switching to Windows for their movie production.

Re:Er?

[rkww]

Hmm, how about Linux-based real time streaming [filmlight.ltd.uk] of 4K 10bpp uncompressed RGB, colour-correcting under alpha masks on the way. That works out at about a Gigabyte per second.

Re:Er?

[stoborrobots]

Just because you can't afford the apps doesn't mean they don't exist
Hear, hear... And what's more, people who make those kinds of trollish complaints often mean that they can't pirate them via Kazaa/Gnutella/BitTorrent therefore they don't exist...

News flash:

[Anonymous Coward]

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 co

Re:News flash:

[Lussarn]

Try playing WoW on a dual head setup with video playing on one screen and the game in the other

I do that every day, works great for me.

NOT primarily for audio/video stuff

[drgonzo59]

Microsecond resolution and RT environment is not for audio/video. You can run your audio and video with the regular Linux kernel. Would you really notice a microsecond delay on a 60 fps (60Hz) frame rate? - I don't think so.

But usecond resolution would be usefull for higher-frequency data processing and control.

Re:NOT primarily for audio/video stuff

[jmv]

Audio doesn't need microseconds, but 1-5 milliseconds is important for some applications. Unfortunately, Linux isn't yet there (dunno whether others are). Even with the latest RT preempt patches, I'm having problems with 1 ms latency. Also, prior to 2.6.12, you couldn't even get real-time priority (required even for 20ms latency) when running as a user (non-root).

Re:NOT primarily for audio/video stuff

[Sycraft-fu]

With Windows it depends on your audio card and API. If you have a consumer card and use DirectSound or MME it's 30ms at least. With pro cards and ASIO or WDM KS it's often configurable. The one I have can be set anywhere between 64 and 2048 samples for it's buffer. That translates to about 1.5ms to 46ms for 44,100Hz and 0.6ms to 21ms for 96,000Hz.

As a practical matter when I set Sonar to it's lowest latency mode, with the drivers at a 64 sample buffer at 96,000Hz it reports the effective latency as 1ms in W

Re:Er?

[fbjon]

Linux could run circles around XP Pro for audio/video apps such as streaming, recording, and playback!

You say that like it's a hard mark to hit.

Yes, but Windows XP will run circles around Linux in those other uses of audio/video, not including streaming, recording, and playback.

beos

[itzdandy]

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

Commodity hardware

[can56]

I've been using the GPL version of RTLinux for years now, in high-speed data logger and control systems in the geophysics and biomedical fields. The problem (difficulty) is not commodity hardware (we've used off-the-shelve P1:P4, AMD, and Via boxes), it's writing the RTLinux drivers, or kernel modules, to communicate with and control the devices, such as a/d cards, serial devices, etc. That is, you can't take an application written for a non-RTLinux system, plop it on an RTLinux box, and expect hard realt

A couple of things about this

[ReformedExCon]

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.

Re:A couple of things about this

[xenocide2]

NT does claim to be suitable for some soft-realtime applications. Most people knowingly waive it off as useless for anything more than trivial applications. NT makes no guarentees about service time, but it has been making strides in improving priority levels, etc. I'm not sure what XP adds to this, since I'm basically pulling this out of a textbook from an influential researcher and author.

RTLinux is generally in the same class. You mentioned that they're using a desktop beast, but those are actually mainf

Re:A couple of things about this

[drgonzo59]

No its not. Once they make a claim that OS will respond in less than 1 micro second, they imply that it is a hard realtime system (i.e. guaranteed response in a certain period of time). If NT can make the same claim then it will be in the same class, otherwise it falls into the "soft realtime" system class (response in an average time).

Re:A couple of things about this

[mollymoo]

You mentioned that they're using a desktop beast, but those are actually mainframe/server systems they're benchmarking on! 256 CPUs, Opteron Dual Core chips, etc.

The AMD Opteron 265 is a dual-core processor. There was just one in the the test machine, it's not a huge mainframe/server system.

Re:A couple of things about this

[CaptnMArk]

>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?)

Scheduler latency may not normally be a big problem, but user interface latency is a problem and UI should be a (soft) realtime system.

Re:A couple of things about this

[julesh]

Yes, it should, but UI latencies of 10ms or higher are not a problem. Most users wouldn't even notice a latency of 20-30ms. I think most OSs use a scheduling timeslice of 20ms -- you can reasonably expect to have that much latency before the app the user is interacting with is scheduled to run, and most users never realize. Much more than that is an irritation; serious usability problems start to appear at about 100ms, which is where users start wondering why the POS is so goddamn SLOW!

Re:A couple of things about this

[Cochonou]

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.

Multimedia

[4of11]

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.

Re:Multimedia

[Arandir]

Realtime operating systems generally suck on the desktop and on server. There's a reason why RTLinux isn't the mainstream kernel.

Re:Multimedia

[kyb]

You need raw CPU for that, not fast interrupts

That's unfortunate - I cooked mine a while back.

a/v doesn't need hard real-time

[Yanster]

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

Re:a/v doesn't need hard real-time

[Anonymous Coward]

To me the numbers announced are on par with hard real-time constraints

One would hope so, from a hard real-time OS [fsmlabs.com].

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. [wikipedia.org]

What about Windows, anyway?

[Sensible Clod]

I'd be interested in seeing the figures for XP X64 with SMP on the same system...

Depends on the app in question

[vectorian798]

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

Re:Depends on the app in question

[hackerjoe]

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

Two things. First, low latency at the expense of a little throughput is actually quite important for pro audio recording, and especially for applications like software synthesizers; it really sucks when there's a half-second delay between twiddling a k

API is limited, too

[j1m+5n0w]

RTLinux, last I checked, was a real time OS completely unlike Linux that was able to run a Linux system as a subtask, much the same as Xen would. Linux tasks would have the same scheduling latency they would normally have, but programs running on RTLinux would have higher scheduling precision. However, you give up a lot in order to achieve low latency - the system doesn't have many of the features most programs would expect to be present, so don't expect, say, Open Office or Firefox to benefit from runnin

Re:Depends on the app in question

[Sycraft-fu]

Usually RTOSes actually have a decreased responsivness, from a user perspective. IF you want to mess with a simple one some day try QNX. I think they still ahve a nice little demo disk you can load. What I found, was that it was nice and all, but it was somewhat slow to respond to my requests. The reason, of course, was that I got no higher priority than anything else.

Well normally for desktop, and espically for AV work, you want a boost on that. You want the video app to get time when it needs it, even if

Multimedia? o_O

[soccerisgod]

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.

Does anyone replying here actually DO MM?

[poptones]

You DO need realtime responsiveness as soon as you start doing mulitmedia OUTSIDE THE STUDIO. Sitting on your ass in your bedroom ripping DVDs doesn't require realtime response, but processing video LIVE does.

So does mixing audio. Because high or unpredicatble interrrupt latency leads directly to longer buffer times needed to overcome jitter, which is a pain in the ass when you are laying down tracks. Every new track based on the previous tracks gets just a little more skewed, which you have to stop and cor

I do

[Sycraft-fu]

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.

Apples to apples?

[Anonymous Coward]

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?

Re:Apples to apples?

[2Bits]

Are you new here? We compare everything to Windows. Bashing MS/SCO/..., kissing the ass of Google/Apple/..., are a daily sport here.

Real time is not only about how fast

[Tetard]

"no more than 5 microsecs" is fine, but -- how the sustained rate, and what about garanteed completion time ? (they have a low boundary too: they shouldn't execute too fast either).

RTLinux is Unfair by Design

[Rick Richardson]

http://www.fsmlabs.com/rtlinux-is-unfair-by-design .html [fsmlabs.com]

Anything else think...

[gorim]

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 ?

Re:Anything else think...

[slashdot.org]

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

Re:Anything else think...

[slavemowgli]

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

Not for your desktop

[AceJohnny]

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.

Software or hardware?

[allanj]

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 [evalue-tech.com](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.

Re:Software or hardware?

[RAMMS+EIN]

``5 us latency is good and all, but that is VERY fast hardware.''

Perhaps, but from a manufacturer whose CPUs have traditionally had slow context switches. That goes for any x86 CPU, by the way.

Good points

[jd]

Also, I'd like to see how RTLinux stacks up against other Real-Time Linux systems - TimeSys does a very nice software real-time and RTAI seems to be doing very nicely on the hard real-time.

Of course, all of these would be a lot MORE real-time if someone would update that damned PPS patch, so we had a good nanosecond clock to work with. When you get to single-digits, small fluctuations (which can't be in units smaller than 1) will be relatively large to the blocks you're working with (in this case, units of

Re:Software or hardware?

[julesh]

you've completely missed the mark. XP is not, will never be, and has never been claimed to be realtime.

"you can easily add real-time capabilities and optimize Windows XP embedded to meet your real-time needs"

http://msdn.microsoft.com/embedded/getstart/prodov erview/features/xp/realtime/default.aspx [microsoft.com]

Although it seems MS prefers to sell WinCE for those with RT requirements:

"a number of significant changes made to the kernel of Windows CE 3.0 have greatly enhanced real-time performance to withstand the most dem

Old news for morons, opinion that doesn't matter

[BarryNorton]

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!

This writer has no idea what he's talking about and launches into a trolling that doesn't even make sense... what's new, this is Slashdot!

but....

[countach]

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

umm...

[mk_is_here]

From TFA: FSMLabs will demonstrate its real-time Linux operating... Flying Spaghetti Monster? Umm.. Intelligent Designed OS... Great

Re:umm...

[mrjb]

For those wondering what he's talking about, here is a link [venganza.org].

5usec is to slow

[jurt1235]

It has to go down to 3usec just to keep up with my double click speed.

QNX

[RAMMS+EIN]

Does anyone know how this compares to actual real time OSes like QNX RTOS?

Re:QNX

[HermanAB]

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

morons

[Madd Scientist]

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

i really hate when people confuse network latency with CPU latency or driver latency or poor software running on the application layer.

Strange: I can't find the source

[Rogerborg]

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.

Re:Strange: I can't find the source

[DaveV1.0]

From the FSMLabs website:

FSMLabs' RTLinuxPro is a tested and validated, hard real-time, POSIX operating system that runs embedded Linux as an application platform...

...FSMLabs patented dual-kernel technology boosts performance and productivity by preventing non-real-time code from interfering with real-time performance...

From this, I gather that RTLinuxPro is an operating system that runs either beside or under neither an embedded Linux kernel.

They do offer RTLinuxFree, which is available with the source. T

Complied with the GPL maybe

[Rogerborg]

But I wonder if they're going to be paid a visit by the Linux trademark police.

Re:Complied with the GPL maybe

[DaveV1.0]

Actually, it may be very difficult to enforce the Linux trademark because it has not been enforced to date. Granted, I am not a Trademark/Patent/Copyright lawyer, but I have read about the laws and cases.

It will be interesting to see what happens if a dispute goes to court. Non-enforcement of trademarks errodes the basis for the claim, which is why it is "tissue" and not "Kleenex ®" and why they are "photocopies" and not "Xeroxes ®".

Of course, FSMLabs may (already have) pony up the money for a tr

RTLinux patented

[Joh_Fredersen]

Doesn't RTLabs, claim to hold a "patent" on running the Linux Kernel as a 'task' under a 'real time' kernel?
http://www.fsmlabs.com/openpatentlicense.html [fsmlabs.com]
http://www.aero.polimi.it/~rtai/documentation/arti cles/moglen.html [polimi.it]

Finally! maybe? Who wants to write a driver? HLEP!

[J_Omega]

In the university lab where I help to research the development of NQR (http://en.wikipedia.org/wiki/NQR [wikipedia.org]) to detect explosives/narcotics/bioagents, our main experimental system's computer is a Pentium 90 MHz running Windows 3.11 and DOS.

We boot into 3.11 because the operational code was developed using Borland C++, but need to exit 3.11 into DOS for the "RT" interrupt capability of the driver for a A/D data acquisition board. You can imagine the hassles that this has given us. It has become a problem just to upload data to our servers.

Our main problem in upgrading the system is that the board hasn't been supported for years, a driver for anything past DOS was never developed, which was proprietary. AFAIK, the company doesn't even exist, and so its unlikey that we could even find someone who might have the code for us to inspect.

IANACoder of much of anything extensive beyond MatLab scripts, and so the idea of myself (or anyone else currently in the lab) wrtiting a new driver for the A/D board. Furthermore, I wouldn't even know where to start to point someone in that direction.

So, I've a muti-part question here, and any input would be appreciated.
1) Would this "rt" linux be up to the task, assuming that drivers are available. (I'd guess that it would, but that's a guess.)
2) How hard would it be, in general, to write a linux driver for this vague hardware?

The easiest solution to our problem might be a complete revamp of the experimental system, but this would cost us well beyond what our current research funding is. Note that wikipedia link, we're one of the few groups worldwide doing NQR research. Such little interest in the field means little funding available, so we'd prefer to be able to reuse as much of the current system as possible.

Any thoughts, ideas, recommendations? Thanks!

Re:Finally! maybe? Who wants to write a driver? HL

[DaveV1.0]

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 differe

It is for systems control, not video response

[Dingo_aus]

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 ;)

Stupid & Pathetic

[Donny Smith]

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

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 /. and make "m$ suckz" and so-called "Funny" comments.

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.

I Can't Believe It Hasn't Been Said...

[_Neurotic]

Imagine a Beowulf Cluster of these!

RT pedants missing the point

[CoughDropAddict]

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.

QNX - 4us on a Pentium 233

[Animats]

QNX reached 4us interrupt latency back on the Pentium 233. In 2001, [google.com]QNX had 4us interrupt response on an iPaq back in 2001. [slashdot.org]

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.

Linux Rocks!

[Entertainment Watch]

Windows could not even handle what I wanted to do when developing http://www.entertainmentwatch.com./ [www.entert...twatch.com] Linux was the only way to go to use Mambo, which rocks hardcore!

Re:Apps

[SillyNickName4me]

You have a valid point that Linux is lackign some applications for music production, but the situation is not as bad as you seem to think, not by far.

The problem is more that if it isn't Cubase, many people don't recognize it as a midi recorder/editor/sequencer. There are alternatives, that may not be as extended as Cubase is, but are quite suitable for most projects. The first that comes to mind is ROsegarden.

With regards to multitrack recording/editing, take a look at Audacity, it seems to do really well

Ehem

[Knome_fan]

"Most of the major studios use Linux -- such as DreamWorks with more than 1,500 Linux desktops and 3,500 Linux servers. The MovieEditor Conference is an all-day event on computer-based filmmaking in downtown Los Angeles on August 3rd. Studio technology chiefs and other experts discuss ongoing work using Linux in feature animation and visual effects. Presented in collaboration with LinuxMovies.org."

http://linux.slashdot.org/article.pl?sid=05/07/27/ 1551250&tid=126&tid=106 [slashdot.org]

Re:One thing I've noticed;

[QuantumG]

The "moderators" don't take any responsibility for the bullshit comments appended by the person who submits the story. That'd be like they were editors or something.

Re:10,000,000 clock cycles?

[Briareos]

Am I the only person who thinks that taking a 10 million clock cycles or more for a dual core chip to respond to an interupt seems like a long time?

What 10 million?

5 usec (that's micro-seconds[1], not milli-seconds) is 1/20,000th of a second, so if you take a 2 GHz CPU it's more like 2,000,000,000 clock cycles * sec^-1 divided by 20,000 sec^-1=100,000 clock cycles...

[1] which should have a mu instead of an u before the second, but SlashDot doesn't seem want to display µ...

Re:10,000,000 clock cycles?

[Briareos]

Ugh... of course, 5usec is 1/200,000th of a second, so it's actually 10.000 clock cycles... *slaps himself*

Re:10,000,000 clock cycles?

[KillShill]

unfortunetly (or fortunetly) you're also the only person to have read the fine article.

Re:10,000,000 clock cycles?

[jmv]

It says 5 microseconds, while the clock period is around 500 ps. That's 10,000 cycles, not 10 million.

Re:10,000,000 clock cycles?

[cnettel]

Yeah, cause you really want the CPU to pump any kind of I/O with no buffering, byte by byte. Heck, even the memory access itself will generally be done in cache lines of 64 bytes or so.

Still, of course, a multi-threaded system won't be able to do real time for every single sample in an audio stream. Video is far easier, you only 30 FPS or so, so all you need is to do the page switch with some accuracy.

Re:10,000,000 clock cycles?

[kasperd]

Moreover, having a second core doesn't make interrupt handling latency decrease

In fact it may even increase the interrupt latency. The fact that a single CPU system could process a network interrupt faster than a dual CPU system was one of the reasons the Horseshoe [dcsc.sdu.dk] cluster was build using single CPU systems.

Re:Linux Rocks!

[J. Random Luser]

slashdot will destroy his spirit, or at least it's destroyed his homepage already...

Re:Already Speedy

[Wonko]

Icecast on Debian Linux already has great performance for streaming, if not "realtime" interrupts

I have no idea why you would need anything remotely like 5 microsecond latency for "streaming." When you stream media you have a buffer at the client end. If you are a bit late with a single packet it shouldn't make any difference.

But I do wonder about loads people have seen with standard datacenter server HW. For example, how many 128Kbps streams can a P4/4.3GHz/128K-cache/512MB-RAM Icecast2 server str

Re:ok great..

[julesh]

I know you're trolling and all, but I have boot times of less than twenty seconds for my P-II/400. This beats every other consumer OS that will run on the system. If I were to strip out as many services as possible, I could get that down to about 5 seconds, although I wouldn't have a very useful system.