Slashdot Mirror
RTLinux Boasts Single-Digit uSec Responsiveness
An anonymous reader writes "A Linux implementation delivering single-digit microsecond responsiveness on 64-bit dual-core AMD Opteron processors is being demonstrated at the Embedded Systems Conference in Boston this week. From the article: "According to FSMLabs, an AMD Opteron 265 dual-core system running RTLinux can deliver guaranteed interrupt latencies of no more than five microseconds, with scheduling jitter of no more than eight microseconds, even with Linux under a heavy load." Heck, with numbers like that it seems like Linux could run circles around XP Pro for audio/video apps such as streaming, recording, and playback!"
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.
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!
The party of stupid and the party of evil get together and do something both stupid and evil, then call it bipartisan.
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.
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!
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 ?
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.
>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.
"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."
/ 1551250&tid=126&tid=106
http://linux.slashdot.org/article.pl?sid=05/07/27
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Does anyone know how this compares to actual real time OSes like QNX RTOS?
Please correct me if I got my facts wrong.
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 µ...
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
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.
If you were blocking sigs, you wouldn't have to read this.
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.
Do you care about the security of your wireless mouse?
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.
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.
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.
a rd.pl?Action=ShowPost&Board=realtime&Post=6&Idle=0 &Sort=0&Order=Descend&Page=1&Session=
AFAIK (well just from reading this)
http://www.linuxdevices.com/cgi-bin/board/UltraBo
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.
as a film maker i agree that the available apps arent as available as one would wish.
f m?Section=Articles&Subsection=Display&ARTICLE_ID=1 18664
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.c
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.
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.
-- *My* journal is more interesting than *yours*...
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.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
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.
they really hate hearing themselves in their headphones if what they're hearing is coming in 100 ms later
caluml:
Well, the human can play along with the delayed recording.
You didn't quite get the "hearing themselves" part, did you? I know firsthandedly that I can not play an instrument well or sing in tune while I hear a delayed echo of myself through headphones. Most people can't. Really!
This is in fact so impossible to normal hearing people, that some division in the (Norwegian) navy used it to outsmart people who tried to avoid the draft. People could simulate near deafness on various tests, but only the real deaf would not be thrown by the simple test: "Read this text into this microphone with these headphones on".
You can get used to it, but it sucks horribly.
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.
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