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

Comments

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

Er?

[DrEldarion]

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

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

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?

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

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

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?

[abandonment]

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

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?

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

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

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

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?

[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 musicians, particularly MIDI musicians, because the latency tended to be very low. This makes perfect sense for arcade hardware.

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

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

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 mainframe/server systems they're benchmarking on! 256 CPUs, Opteron Dual Core chips, etc. These chips feature lots of stuff you can't afford in the bulk of embedded systems.

The only thing this appears to be useful for is low latency financial market trades. If they were going after the embedded system market, perhaps an embedded system benchmark would suit better.

Also, how can your RTLinux feature a RTCore based on ruggedized Linux or BSD? How much of this system is Linux, exactly? Perhaps a trademark litigation is in order over this?

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

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

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.

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

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

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.

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 knob or pressing a key and hearing the effect that has.

Second, there's a much better reason that RTLinux is irrelevant, even to the pro audio stuff that wants a real-time kernel: real-time processes in RTLinux can't access the Linux kernel, they can only access the RTLinux core. This means they would need special drivers for audio, MIDI, and so on, and any access to the file system or any other normal OS or userland service would have to go through a pipe to a non-realtime server -- super annoying.

This is why Linux audio developers are still pushing for at least soft-realtime performance in the stock kernel. RTLinux is good at what it does, but it's really only practical for systems that are deployed on limited hardware, such as telecoms systems and other embedded systems, where the appropriate drivers can be built into the application.

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 it starves another application. You'd want higher responsivness to it's requests for things on disk and response to user commands then some network process running in the background.

I think an RTOS would probably be the worst choice for an AV workstation.

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 core opteron just so my linux box can play video and sound without stuttering under a load.

Try playing WoW on a dual head setup with video playing on one screen and the game in the other. Windows handles it amazing well, while linux chokes horribly. This can be somewhat alleviated by reniceing the process, but that kind of defeats the purpose of the whole "low latency desktop" thing, doesn't it?

IMHO, audio is perhaps the one place where choice hasn't helped linux.

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.

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

Linux Rocks!

[Entertainment Watch]

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

RTLinux is Unfair by Design

[Rick Richardson]

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

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

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!

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.

Re:Everyone is convinced

[Anonymous Coward]

Exactly, "real time" != "real fast", real time just means "predictable".
The important thing is not to respond fast, but to ALWAYS respond within a KNOWN delay.

Re:Everyone is convinced

[Xiaran]

that "real time = real fast."

Yes. I used to work on hard realtime applications and it is a very specific term that doesnt really have anything to do with speed, but with assurances that response will happen in a certain time period.

An example of a hard realtime system I heard of once that didnt require a lot of fast responses was on a oil rig. Im not 100% sure what this system did but it had to do it every hour to an oil pump. If it *didnt* do this thing every hour then "bad things happened". Typically these bad things involved pipes exploding and people catching fire.

Re:Everyone is convinced

[Anonymous Coward]

Windows CE 3 and later are true real time systems.

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?

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 WDM KS mode. In ASIO mode, it claims 0.7ms lattency at 96,000Hz.

I don't have any way to test Sonar's claims, but I don't have any reason to doubt them either. Also not sure how well it'd handle heavy use, you might get droupouts, though it plays back a track just fine with that setting.

I believe on both Windows and Mac with ASIO compatible software and hardware, 1-2ms latencies are very attainable. I personally don't mess with it since I don't do live recording, but the software and hardware seems to claim it can handle it.

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 running on such a system.

On the other hand, maybe my understanding is wrong or out of date (if so, then someone please correct me).

umm...

[mk_is_here]

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

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

5usec is to slow

[jurt1235]

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

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 5, making fluctuations smaller than 20% unmeasurable and fluctuations greater than 20% likely).

With a working PPS patch, you'd have a thousand times greater accuracy on the clock, therefore random errors would be a much smaller - and much more quantifiable - amount of the time spent, allowing for better adjustment and therefore better Real-Time.

Now, would anyone NEED nanosecond accuracy? Hell, no. Would it be COOL to have nanosecond accuracy, just because? Well, of course! So long as it didn't detract from anything, then anything geekier is automatically sexier.

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 realtime response -- you have to rewrite it.

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*

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.

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:Linux Rocks!

[J. Random Luser]

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

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: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 cluster was build using single CPU systems.

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.

Re:Well I suppose it should be clarified

[che.kai-jei]

as a film maker i agree that the available apps arent as available as one would wish.

that linux list?

thats muscley studios flexing. showing the horrible vertical proprietary solution providors of old that they are sick and tired. im lookingh at you, you AVID assholes.

you conventiently omit AVID from your list. final cut pro will never beat AVID - some of the expensive apps you mention in combination are adequate replacements with the massive amounts of financial muscle and high end in house bespoke IT support the studios wield.

what you are doing? comparing apples to the causes of the franco-prussian wars.

as a programmer and free software advocate i take exception to your whining about software because i get the feeling you should know better.
which lone programmer writes a FC Pro beater on linux to scratch his "need an editing soloution itch"?
your sentiment however does represent multimedia creator users' needs.
i am irked by the fact that the big companies havent open sourced any of their general puprose tools like ILM promised to.
http://cgw.pennnet.com/Articles/Article_Display.cf m?Section=Articles&Subsection=Display&ARTICLE_ID=1 18664

however if the market is there a smart guy may hire a team of great programmers to come up with an AVID beater.

also the mac OSX intel move may change thigs around for these products which were mac/win only.

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.

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
http://www.aero.polimi.it/~rtai/documentation/arti cles/moglen.html

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

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

RTlinux ~ Audio/Visual

[DeckerDel]

The services real time processing provides are often not required by the needs of an application. This is the case when low-latency servicing of events is needed but the complexity and potential deadlocks of a real time os are not desired. Video/Audio recording is an example of an application that needs low latency but not necessarily real time os services.

AFAIK (well just from reading this)
http://www.linuxdevices.com/cgi-bin/board/UltraBoa rd.pl?Action=ShowPost&Board=realtime&Post=6&Idle=0 &Sort=0&Order=Descend&Page=1&Session=

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 different/newer/supported card for this experimental system?

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.

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.

Re:QNX

[HermanAB]

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

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.

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

[Anonymous Coward]

The above poster makes many good points, but he could not be any more wrong about RTLinux being low throughput and limited to simple tasks.

You can do lot more with RTLinux than just "very simple, limited code that runs in a real-time mode". In kernel space you can do complex tasks but RTLinux also supports hard realtime in user space via the PSDD interface. You can run large complex code + I/O all in hard real time in user space.

In my job we use RTLinux to run complex gas turbine simulation in hard real time doing lots (400 + channels of A/D, D/A, frequencies, etc) of hard real time VME base and PCI I/O

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.

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

[_Neurotic]

Imagine a Beowulf Cluster of these!

Re:less latency for a given process

[natmakarvitch]

use the 'chrt' (think "change real-time attributes) utility (Debian: 'schedutils' package)

beware: chrt'ing a badly implemented application may provoke a kernel hang

--
WebDSign: thrust the Web by trust

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.

WTF mods?

[SmittyTheBold]

It's not "funny," it's true.

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, and offers more features then many will need.

Maybe I am a bit old fashioned, I actually use a real mixer and a stack of effect equipment for recording (all physical equipment, not virtualized).. This may make the mentioned software a bit more acceptable.

But the problem remains. People do not look for the specific functionality they need and try to find a solution that matches it well, instead they look for the program they know, or by lack thereof, something extremely similar.

QNX - 4us on a Pentium 233

[Animats]

QNX reached 4us interrupt latency back on the Pentium 233. In 2001, QNX had 4us interrupt response on an iPaq back in 2001.

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.