Linux Kernel Goes Real-Time

Several readers wrote to alert us to the inclusion of real-time features in the mainline Linux kernel starting with version 2.6.18. (Linus Torvalds had announced 2.6.18 on September 19.) Basic real-time support is now mainline. This will ease the job of developers of embedded Linux applications, who for years have been maintaining real-time patch sets outside of the mainline kernel. The announcement was made by TimeSys Corp., a provider of developer services. Much of the work was done by Thomas Gleixner at TimeSys and Ingo Molnar at Red Hat.

Comments

What about media?

[stonedyak]

The article only talks about these new patches from the embedded devices point of view. So can anyone tell me if these new features would be useful for improving the responsiveness of media applications in Linux? I'm talking about video/audio playback, as well as authoring and recording.

What other benefits would the desktop see from this?

Re:What about media?

[norkakn]

No. RT has a pretty big speed penalty.

Re:What about media?

[iotaborg]

The desktop probably won't see much from having a realtime kernel. A RTOS is great for integrating certain types of hardware, such as data acquisition systems, which can be time dependent. We use RTAI Linux at the lab for time-accurate data acquisition and control system in robotic applications. Most 'desktop' processes do not really depend on time; video and audio playback do, though without a RTOS video/audio play just fine. I do not believe you need kHz-MHz resolution for any desktop application for timing.

Re:What about media?

[SmileR.se]

No. Real-time is about being able to guarantee that tasks complete within a certain deadline (and ofc being able to predict this deadline), not doing things fast.

Re:What about media?

[fossa]

But desktop users, or at least me, don't care about doing things "fast". I care about things feeling fast. I care about latency. So, do these patches help the audio on my computer not skip when I move a window? I've tried the premptive kernel patches in the past with no noticeable difference. How are these patches similar, different, or complimentary to Ingo Molnar's (whose patches are mentioned in the article). Thanks.

Re:What about media?

[Bacon Bits]

Desktops and most servers do not get any benefit from a RTOS. RT makes it so that the system purposefully downgrades less-useful things like user input for maximum priority things like, say, polling a fetal heart monitor every n milliseconds or responding to an automobile collision to deploy an airbag.

RTOS in Linux is primarily useful for Linux-based routers. However, seeing that QNX has been in the industry for 25 years, has an extremely good reputation (it's the de facto standard in the auto industry), and is already POSIX compliant, Linux still has a long way to go. The price for QNX might be USD $10,000+, but if you actually have a need for a RTOS, licensing cost is not a major obstacle.

Re:What about media?

[novus ordo]

You are right, to a certain extent, but take audio/video work as an example. If I am using my computer as a synthesizer, I want to be able to hear the keys as they are being pressed, not 0.5-2 sec later. Even if the mixing part would take longer than the time I press my next key, the kernel should process that key anyway. Music is a weird thing.. a couple of milliseconds difference is enough to change the perception of a note. So in this case, it will 'seem' faster, even though it will have less throughput(context switches the mixing process out even though it has the mixing data in the cache which conveniently gets invalidated, swapped, etc.) I guess it gives certain applications the super-duper dependent on time factor that would otherwise be overlooked in the ways kernel measures "fast."

Re:What about media?

[bazald]

While you are right, you seem to have missed his point entirely. One of the biggest applications of real-time scheduling for normal users (rather than pilots and nuclear plant controllers) *is* media. Pick up a text book on operating systems, and scheduling of media applications (audio, video, ...) is practically the first thing they get to.

I for one believe that it could be immensely useful for Linux to provide the option of switching to a real time scheduler when starting a video playing - and for it to be able to tell you that there is no chance it will be able to run certain videos (HD for example) on older hardware.

Re:What about media?

[flithm]

I get what you're saying, but if I didn't know better what you said could be a little misleading. To be totally correct a real time operating system has nothing to do with task completions, but rather with providing the ability (often mathematically proven) to respond to interrupt and thread context switches within a pre-determined (and known) time constant. This is generally referred to as the interrupt or thread switch latency.

And actually the grand parent is right to wonder about whether or not this will allow for a more responsive feeling system, because in general, it will. Much more so than the pre-emptive kernel routines already in = 2.6.17.*. If you've ever used a real time OS you'll know what I mean -- nothing feels so nice to use. The processor can be pegged, and have a ridiculous load average of say... 100 or something (100 tasks are trying to use 100% of the CPU), and you won't really notice any sluggishness... but, of course, tasks will just take a long time to complete.

It's not without it's downfalls though. Obviously being able to guarantee low latency interrupt responses is going to require some overhead. You'll definitely slow your computer down by using a real time OS, although unless you're a gamer you might not even notice.

All that said and done, unless you're using your computer for some very specific things like embedded devices, critical applications (medical, power station management, etc), and audio / video stuff, you'll probably never notice the difference.

I know a lot of audio people are happy about the real time patches because the delay between turning a dial, or moving the mouse, and the noises that come out of the speakers is quite noticeable even with really small delays.

Re:What about media?

[javilon]

For a long time, people using JACK (a low-latency audio server, written for POSIX conformant operating systems such as GNU/Linux and Apple's OS X) have been using real time linux patches to achieve better results. So for this kind of pro audio users, using Linux workstations (not embedded linux) it is quite nice to have included in the official kernel.

Re:What about media?

[glarbl_blarbl]

Music is a weird thing.. a couple of milliseconds difference is enough to change the perception of a note.

Actually, the human ear is capable of detecting two discrete notes if they are separated by at least 30 milliseconds. If you set your digital delay to anything shorter than that, it won't sound like an echo - it will sound like the delayed signal is part of the original signal. Your example of a synth producing a note half a second after you hit a key is spot-on though, you'll notice that and be pretty annoyed if you're trying to do an overdub.

http://ccrma.stanford.edu/planetccrma/software/ has offered a real-time kernel for as long as the project has been around, for the above reasons - and if you're trying to record 8 tracks of audio at 24b/96kHz you'll quickly realize that the kernel has to be able to handle all of that data precisely, or your drum kit recording is going to sound awful.

Re:What about media?

[tuba_dude]

Interesting project page, I'll have to check it out later. I agree about the pains of delays in digital recording, because even when they're unnoticable live, they're a pain in the ass to account for. (Why doesn't somebody add a routine to track and account for that delay in a multitrack recording program?) I've always had an issue with people say "the human X can't detect Y" where X is a sense organ and Y is a related phenomenon of relatively minute proportions. A lot of people tell me they can't hear the difference between 128kbps MP3s (I'm unsure of the details of the format, but even at 320kbps, isn't there a change in the waveform? That could techincally be detected too.) and the original CDs and that sort of thing, but for different people, they'll be able to discern different things. I can hear the hum from almost any CRT in a relatively quiet room, for instance. Sure, most people won't notice, just like most people won't notice the 3 or 4 viruses they probably have on their computers right now. I don't know, I'm just complaining. It's just frustrating when someone tells me that I can't detect something that I know I can. Just a tip for any current or would-be audio software programmers out there: Don't tell a musician what he can or can't hear. Either adjust your program based on the feedback or explain why the descrepancy is there. Sorry, enough ranting for me.

Re:What about media?

[dodongo]

A lot of people tell me they can't hear the difference between 128kbps MP3s (I'm unsure of the details of the format, but even at 320kbps, isn't there a change in the waveform? That could techincally be detected too.) and the original CDs and that sort of thing, but for different people, they'll be able to discern different things.

If you're really interested, I have some spectrograms of what OGG and MP3 do to a waveform. The data rate is undoubtedly important, but you also have to take into consideration the sample rate (which controls how many samples per second the decoder has to interpolate a waveform and side effects thereof) and the number of quantization bits available, which controls the resolution of the individual samples. Plus, MP3 has a lowpass filter which is somewhere between 16kHz and 19kHz, which for certain musical passages is really noticeable, though not so much so for just voice.

AFAIK, MP3 is by nature always a lossy codec, with no option for lossless encoding. If that's true, no matter how much information you want to make available to the encoder, you'll never be able to match the original waveform.

Re:What about media?

[glarbl_blarbl]

I know what you mean, and IMO many times sensory limitations are generalized to the entire population while extraordinary indviduals who spend time training their senses will be able to exceed them. I had the benefit of learning from professionals in audio production in a collegiate setting, and the I bet most people can't hear the difference between DVD quality and CD quality, and most of the consumer gear doesn't help there... I guess it's splitting hairs, but audio professionals who truly respect their craft will always strive to present the musicians' intent in the most transparent manner possible. I've always thought that breaking rules didn't mean much until I knew what they were.

Re:What about media?

[cheater512]

lol. A realtime kernel will make the problem worse.

They are good for very specific purposes, not multitasking.

Go buy a faster CPU. I dont have any audio skipping problems on my P4 2.4ghz.

Re:What about media?

[glarbl_blarbl]

Weird. /. seems to have edited my post, it's plain old text from now on, dammit.. That what I get for skipping preview I guess. Here's what I meant to say:

I know what you mean, and IMO many times sensory limitations are generalized to the entire population while extraordinary indviduals who spend time training their senses will be able to exceed them. I had the benefit of learning from professionals in audio production in a collegiate setting. The ~30ms rule was one I heard from many of my instructors and verified for myself a number of times (on analog and digital gear in state of the industry studios). Since I graduated 9 years ago I have been actively training my ears, I have also been a multi-instrumentalist for nearly twenty years. So take from that what you will.

I bet most people can't hear the difference between DVD quality and CD quality, and most of the consumer gear doesn't help there... I guess it's splitting hairs, but audio professionals who truly respect their craft will always strive to present the musicians' intent in the most transparent manner possible. I've always thought that breaking rules didn't mean much until I knew what they were.

Re:What about media?

[Pseudonym]

Real-time is all this and more.

Getting tasks to complete on time is actually not something that an operating system can guarantee: you can simply lie about how long your job will take. (But, like your compiler, if you lie to your operating system, it will get its revenge.) Or you can design your hardware so that it swamps the system with so many interrupts that it can't service any user tasks. This kind of problem is a property of the system as a whole, and the best that the kernel can do is guarantee that if you play by the rules, it will too.

Latency (be it interrupt delivery, signal delivery, context switch or whatever) is something that the kernel can guarantee for the most part, but even then, in an OS like Linux, where hardware drivers are part of the kernel, you also rely on those drivers to play nice. This means, for example, that it must not disable interrupt delivery around a loop.

The other main things you need are things like the ability to fix data in memory (which Linux has had for a while), fixed-priority tasks and the ability for a task not to be preempted by a task of the same priority.

Re:What about media?

[jedimark]

Realtime patches make it a lot more practicle for stuff like audio processing - sound comes in line-in, gets worked over and send straight out to line-out - all in less than 5ms. I've found these 2.6 patches better than the realtime-lsm stuff.

As for your sound playback is skipping...

You can up the pci latency on your audio card.. (using setpci) but that wont solve everything.. for instance sound still has to load from the harddisk, so the latency for the controller has to be up too.

Something could be sharing an IRQ with your soundcard or something else that makes things clag up.. (For instance, a pci network card can interfere with onboard sound card plugged into a certain PCI slot)

Of course, your computer could just be too slow. and some chipsets just plain suck. (eg older VIA stuff, which I unfortunately is in the majority of my computers)

My soundblaster audigy card cacks out at 5ms, so I took it out tried a whole bunch of s/h crud from my soundcard box, and now use an old SB Vibra128 (CT4810) and get near zero latency for music recording. So I guess the type of soundcard can have an impact on stuff like that.. I found CMI soundchips to be the absolute crummiest in terms of latency (and have had plenty of skips with them in ordinary desktop machines)

Re:What about media?

[kimvette]

If you're doing transcoding or 3D rendering, you want it to be fast, and you certainly do not want non-reenntrant libraries (like some shared Gnome or KDE GUI libraries) hogging processor time. Hopefully a realtime kernel will help to ensure that the background threads receive the processor allocation they should be getting.

Re:What about media?

[deanj]

Not if the process you're using is a realtime process, which is what you'd want anyway.

Re:What about media?

[deanj]

You're not going to see anything really great until they finally bite the bullet and make the kernel fully pre-emptive. The hacks in there now to have multiple processes in kernel context aren't nearly as effective as fully semaphoring the data structures in the kernel but 1) It's hard, and 2) the kernel jocks doing the kernel these days haven't been too happy about it.

But sooner or later, they'll have to. Multi-core/multi-processor single box systems will greatly benefit from it.

Re:What about media?

[Anonymous Coward]

I'm sure both of them are very excited right about now!

Re:What about media?

[wish bot]

This is a neat idea and a good point. However, you may find that you get an OS X situation, where the scheduling works brilliantly for media but is pretty hopeless for tasks like the infamous mySQL database test. I have heard of people who recompile their own scheduling into OS X for use with databases that increases the performance dramatically. Maybe there could be different flavours of Linux distributions - media, or development - that are more suited to each task.

Re:What about media?

[eggstasy]

Desktops do benefit from a RTOS. RT makes it so that the system purposefully downgrades less-useful things like buggy apps that go into infinite loops for maximum priority things like, say, user input.

Re:What about media?

[Anonymous Coward]

Yeah, like the way Amarok "locked up" my computer for several hours yesterday. All I did was tell it to rescan the collection, and first the KDE desktop stopped working (clock wouldn't update the time, can't switch desktops, and stuff like that) then everything running from X stopped listening to the mouse and keyboard events. It took 30 minutes to ssh in from the LAN here, and when I accomplished that feat I couldn't do anything. Later on even ssh stopped working: it would accept a connection then immediately close it.

Eventually my computer came back to me, but not after trying to kill the amarok collection scanner a few times.

As far as I can see, the problems are several - when amarok starts scanning it does something nasty to KDE and doesn't stop it until the scanning is finished. Secondly, when scanning an AAC file, it seems to loop reading the same data from disk forever. Thirdly when scanning files, the disk drives are somehow monopolised by the scanner, so it's impossible for anything else to read the disk in a timely manner. That causes processes to run slowly, and loadavg builds up (due to cron, incoming server connections, and stuff). When loadavg gets high it's possible to SSH in but it takes many minutes and anything which requires disk I/O appears to hang. When loadavg gets very high, sshd detects this and drops connections (or maybe it's tcp_wrappers doing it).

Applications should not be able to monopolise the computer to the extent that everything else just freezes. If it's a problem with the disk I/O I'd like to see what reconfiguration of the hardware will fix it - this is just two SATA drives on the inbuilt SATA adapter, in a RAID-1 array.

Re:What about media?

[nebosuke]

Embedded real-time operating systems and what you're referring to (a process priority level) are two entirely unrelated things. The process priority setting we call 'realtime' simply tells the scheduler that the designated process always preempts other processes whenever it asks for processing time (e.g., it will consume all of your CPU unless/until it sleeps). A real-time OS, on the other hand, is an OS designed such that the length of time any given system call takes to complete is deterministic. This is necessary for embedded systems so that you can make guarantees about the performance and state of the system. Being able to do this is a requirement for many types of mission-critical software, such as avionics, medical device control, heavy equipment control, etc.

Re:What about media?

[code4fun]

You probably need a faster machine or faster graphics card.

Re:What about media?

[dbIII]

Fourthly - you probably need more memory to do tasks like this - things that do a lot of I/O and then start going into swap as well really can bring computers to a standstill.

Re:What about media?

[deanj]

Yes, I understand what a realtime OS is. I worked on kernel teams (for non-embedded UNIX systems) for several in the 90s. I didn't mention anything about embedded real-time OSes, because it's irrelevant to this discussion.

Anyway, that was exactly my point.

The realtime process in a realtime UNIX kernel can help an audio application by being able to field interrupts in a deterministic fashion.

Furthermore, a fully preemptive kernel (ie, all the kernel data structures protected) with multiple processes being able to be in kernel context at the same time can bring even regular (non-realtime) computer tasks.

If you think Linux is zippy now, wait until they do the really hard work to make that kernel fully preemptive. The systems will REALLY fly then.

Re:What about media?

[ffflala]

If you've ever tried to multitrack using Audacity and ended up with mush, you'll know why this is great news. It will sound in sync while you're recording to the first track, but upon playback the 30 ms (or longer) delay wreaks havoc.

Planet CCRMA http://ccrma.stanford.edu/planetccrma/software/ a Fedora Core distro that uses the realtime preemption patch by Ingo Molnar to achieve low-latency. DeMuDi is Debian customized for audio production by the Agnula project http://demudi.agnula.org/ and uses JACK. I'm curious to see what this development will have on these and like-minded audio production Linux distros.

Re:What about media?

[Bacon Bits]

Yes, but adding in RT checks adds a lot of extra processing. Essentially, the system will have to stop and check to see if it's time for an RT operation when it would otherwise be doing work. And if the RTOS is doing multiple things in real time, well, it just gets that much more complicated.

If a normal OS would *really* benefit from RT operations, don't you think that Linux, AIX, or Windows wouldn't have already implemented it? RT processing is only necessary in very specific applications. Almost all of them are for industrial equipment, safety equipment, and medical equipment where a few milliseconds of real time is actually important. A normal OS is concerned with *how quickly* something will occur. A RTOS is concerned only with *when* something will occur. It sacrifices performance for predictability.

Re:What about media?

[Anonymous Coward]

"If a normal OS would *really* benefit from RT operations, don't you think that Linux, AIX, or Windows wouldn't have already implemented it?"

Consider the same questions years ago:

"If a normal OS would *really* benefit from X, don't you think that Linux, AIX, or Windows wouldn't have already implemented it?", with X being "demand paging", "virtual memory", "preemptive multitasking", or (even longer ago) just "multitasking", and the OS with ProDOS, MS/DOS, DR DOS, Mac OS, or whatever was prevalent at the time.

With processor speed no longer being an issue for most things users do at home, it may become worthwhile to spend some of that CPU power on diminishing latency, or even only on diminishing fluctuations in latency (example: playing back music at 99.9% of the correct speed may be way less noticeable than playing it back at a speed that randomly varies between 99.9% and 100.1%)

Re:What about media?

[Anonymous Coward]

Umm, yeah. Those things were useful, so operating systems like Linux and AIX implemented
preemptive multitasking, demand paged virtual memory almost from the get go.

What's your point?

Re:What about media?

[Anonymous Coward]

Go buy a faster CPU. I dont have any audio skipping problems on my P4 2.4ghz

Or just use Windows, which does not suffer from these problems, and doesn't need a 2.4Ghz CPU. So much for Vista's high requirements...

Re:What about media?

[Znork]

As far as I can tell, it looks pretty much like the same patches that CCRMA uses (but I could be wrong), which should in theory help, in the event that your problem is related to latency issues.

However, in my experience, under any normal circumstances (ie, machine produced in the last decade, not doing massive multitrack music composition and playback), you're vastly more likely to run into driver problems causing skips. Any non-prehistoric machine (500MHz+) should easily be able to playback an MP3 and not skip while moving windows, even without realtime audio.

Re:What about media?

[billhuey]

>Yes, but adding in RT checks adds a lot of extra processing. Essentially, the system >will have to stop and check to see if it's time for an RT operation when it would >otherwise be doing work. And if the RTOS is doing multiple things in real time, well, >it just gets that much more complicated.

I suggest you look at the -rt patch implementation. It's far from that in that it's mutex based with a irq-threads backing it. The claim it's going to be much slower is ridiculous. That's just flat out ignorance with how concurrency is done in the -rt patch. Fully preemptive doesn't mean "check rescheduling all of the time". I should know. I did a parallel implementation of this patch and was quite successful.

Re:What about media?

[jb.hl.com]

Hang on. Foobar2000 can scan a full collection on machines with very little memory to begin with. What makes Amarok require lots more?

Re:What about media?

[Ant P.]

Things that start going into swap over such a trivial task should get killed by an out of memory exception, not be allowed to hard lock the machine for hours. Especially not non-root userspace apps.

Re:What about media?

[Julian Morrison]

Realtime can be divided into hard realtime, which gives deterministic guarantees on latency, and soft realtime, which gives no guarantees but can be expected to deliver low latency more often than not. Hard RT is the one that's slow, because it does things like fixed-timeslice round robin scheduling. Linux, when not built as a layer above a specialist microkernel, is soft RT.

Re:What about media?

[ccarson]

Furthermore, a fully preemptive kernel (ie, all the kernel data structures protected) with multiple processes being able to be in kernel context at the same time can bring even regular (non-realtime) computer tasks.

That's interesting. So are you saying that unprotected kernel data structures are being manipulated by outside kernel processes which in turn cause more kernel processes to react and therefore slow the system down?

Re:What about media?

[RegularFry]

You're right to ask, but it shouldn't matter. Both the kernel IO/swap interaction and Amarok must be at fault. A user-level application should *never* make a machine unusable - if it happens, it's a kernel failure. Causing it in the first place is a design flaw in the application.

It could be argued that preventing this situation is analogous to solving the halting problem. I've never seen it couched in those terms, but I wouldn't argue with it if it was.

Re:What about media?

[joto]

Actually, windows isn't any better than linux for audio tasks. It's just that linux lacks the useful software. What people really want is something that is better than windows for audio-processing tasks. Not something that is on par with windows, we already have that.

Re:What about media?

[joto]

Go buy a faster CPU. I dont have any audio skipping problems on my P4 2.4ghz.

Neither did I on my Pentium 90. To get audio skipping with audio, you either need to use low-latency processing, or have a ridiculously busy box. Realtime will help low-latency processing run more reliable, and can also help by giving selected tasks higher priority, which will solve both problems. (And yes, I know what realtime means, and no, I'm not speaking in general, I'm speaking of this specific set of patches to linux).

Re:What about media?

[Anonymous Coward]

"If you've ever tried to multitrack using Audacity and ended up with mush, you'll know why this is great news. It will sound in sync while you're recording to the first track, but upon playback the 30 ms (or longer) delay wreaks havoc."

Realtime is not about keeping new recordings in sync with prerecorded material.
The problem with audacity you mention is a bug. The software should know the latency and compensate for it.
As there will always be latency, even with small buffer sizes, the software always has to compensate.

You can track perfectly well with a non realtime kernel, just use large (2048 frames +) buffers and monitor through the sound card's mixer, or a mixing desk.
Realtime is only needed for live monitoring with effect plugins or playing soft synths from a keyboard.

Re:What about media?

[deanj]

No. I'm actually saying something different.

In a "classic" unix kernel, only one process is in kernel context at a time. That's because if you have more than one process in kernel context at once, there's a good chance that they'll step on each other.

Say that two processes were in kernel context at the same time, and one wanted to delete data from a data structure and the other wanted to read from it. If the process that wanted to read from the data structure got a pointer to it, and then before it could do anything with it, the process that wanted to delete it came in and did delete it, when the process that wanted to read from that pointer it just grabbed came back, it would fail, and probably cause a kernel panic.

If all the data structures in the kernel are protected by semaphores (and spin locks in case of interrupt routines), and all the paths through the code prevented deadlocks (that's one of the tricky parts), then multiple process could be in kernel context at the same time.

You'll get the speed up because in a classic UNIX system if a process in kernel context took a long time with what it was doing, it effectively locks out all the other processes that want to go into kernel context until it's complete. When you have everything set up so that multiple processes can be in kernel context at the same time, you move the contention from the entire kernel down to individual data structure manipulation, and the wait times are much lower.

I believe (and someone that's actually still reading this correct me if I'm wrong), they do have semaphoring of code within the Linux kernel right now, but it's over big parts of the code, rather than individual data structures. There is some benefit of doing that, but not nearly the benefit of doing those individual data structures.

It's tough, but worth it in the end. I think the hardest part of this will be the drivers, and making sure that they behave well in a system like that.

Re:What about media?

[Breakfast Pants]

If you are running a window manager in that makes dragging occur in outline mode on X, and you have audio playing in Firefox in a flash applet (e.g. with youtube or pandora), no matter what your kernel is you will get skipping in your audio. This is because when dragging around in outline mode in X nothing is allowed to draw to the screen, and either firefox or flash just basically lock up.

Re:What about media?

[ccarson]

Gotcha. Thanks.

Re:What about media?

[Anonymous Coward]

RTOS in Linux is primarily useful for Linux-based routers. However, seeing that QNX has been in the industry for 25 years, has an extremely good reputation (it's the de facto standard in the auto industry), and is already POSIX compliant, Linux still has a long way to go. The price for QNX might be USD $10,000+, but if you actually have a need for a RTOS, licensing cost is not a major obstacle.

All of which, of course, doesn't mean squat.

In 1990, proprietary Unix had been in the industry for 25 years, had a good reputation, cost thousands of dollars, etc. Look at how many non-Linux Unix workstations are being sold these days.

It's amazing what a free-software, zero-cost, good-enough alternative can do to a proprietary industry, and how fast.

Re:What about media?

[The_Wilschon]

Yeah, you missed the point. There was a time at which OSes (like the various DOSes that were mentioned) didn't implement those things. At that time, we could have made the argument that "well, if those things were useful, we would have implemented them in every OS long ago". However, that argument would have been wrong at that time for those things. So, by analogy, perhaps the argument "if RT processing were useful on the desktop, Linux, Windows, and AIX would have implemented it long ago" is also wrong today. That, I believe, was the point.

Re:What about media?

[Anonymous Coward]

Yup. Agreed, the argument is ridiculous. Or flip it around: QNX has RT, but since Linux, AIX and Windows don't, QNX having RT is useless. If you know what and where QNX is used know how long it has been around (I vaguely know), you know this is quite ridiculous, too. We could even draw some hilarious microkernel vs monolithic kernel debate from this, by making analogies, but I refrain. Realizing different OSes serve different goals is a more healthy viewpoint to work from.

Re:What about media?

[Henk Poley]

The desktop probably won't see much from having a realtime kernel.

Well, the changes to the kernel to support some sort of usable realtime system have improved the responsiveness of the kernel greatly. Probably none of the programs on my desktop will ever need hard realtime. But boy, do I like it if my programs keep responsive under heavy I/O from other programs.

I do not believe you need kHz-MHz resolution for any desktop application for timing.

Well, to each his own. Like I said probably none of the programs I run will use realtime 'contracts' with the kernel. But I expect this change to be as import as using a "server grade" operating system on the desktop. Just like everybody likes stable computer programs (and OSes), they also like responsive programs. And OSes will need to support that too, and for this support they'll need to change, for the better.

Re:What about media?

[thethibs]

Obviously being able to guarantee low latency interrupt responses is going to require some overhead.

That's not obvious at all. An OS designed to support RT will feature the fastest task switching the hardware can support. Since task switching is what the overhead is, that also means minimum overhead.

There are two overhead effects to handling an interrupt: parking the executing task and starting the interrupt handler, and deciding what to do when the interrupt handler exits. With a good queued design, the overhead drops as the number of tasks increases because (simplifying) it's easier to find the next thing to do.

This is not rocket science or a radical new technique—it was a feature of SDS UTS in 1970.

Re:What about media?

[sydb]

Maybe there could be different flavours of Linux distributions - media, or development - that are more suited to each task.

There are media-tailored Linux distributions - StudioToGo and 64Studio. Also there are things like PlanetCCRMA, AudioSlack and the Gentoo Pro-Audio overlay that can tailor a vanilla distribution to the needs of an audio workstation.

Re:What about media?

[u38cg]

I'm not an expert on audio perception, but I do know that I can play and hear up to 24 distinct notes per beat at 120bpm, which by my calculations works out at just under 21ms. That's playing a monophonic (wind) instrument, though.

Re:What about media?

[egghead_y2k]

I've been working with systems that support extent writing for many years (JFS2 mainly in the *nix world). While the overall performance is increased on read/write and seek times (especially in RAID-5 or any other striped RAID for that matter). For a desktop support for extents is just another over kill. All were seeing is the transition of technologies which have been in the commerical space coming home to desktop users. SMB/SME will benifit from such transitions but with improvement comes increased complexity and therefore risk... If you running a desktop ext3 and even ext2 is most cases works fine.

This has got to be a good thing!

[ztransform]

Many arguments are out there for and against Linux as a real-time embedded operating system. But with embedded processors getting more powerful and there is growing popularity with the Linux kernel anything that makes the job of an embedded developer easier (and standardised) is a good thing.

Re:This has got to be a good thing!

[Anonymous Coward]

There are some design decisions that affect both ends of the spectrum. Linux runs on tiny hardware (embedded) to some of the largest (clusters, mainframe) and what works for one may have deleterious effects on the other. Luckily, the real-time patch does not necessarily conflict with the large systems, and could possibly be good.

Re:This has got to be a good thing!

[Pseudonym]

BTW, it's a fallacy that "embedded" implies "tiny". Sure, a heart pacemaker is an embedded device, but so is a digital set-top box and so is an MRI scanner. Many modern embedded devices have demand for quite a bit of computing power.

It is about time!

[statusbar]

It sure is a about time! But what about Xenomai?

--jeffk++

Yes, but what does it do?

[j1m 5n0w]

There has been a substantial ongoing effort to provide real-time support in Linux for quite a few years now; what do these particular patches do that hasn't been done before?

Re:Yes, but what does it do?

[Nutria]

what do these particular patches do that hasn't been done before?

Make them an official part of the kernel.

I'd ask if you RTFA, but of course it's pointless.

Re:Yes, but what does it do?

[Anonymous Coward]

The other extensions *were already* made part of the kernel, so his question is still valid.

Re:Sliced bread next?

[Anonymous Coward]

Wow got geek envy ? Were you a bully when your were a child ? Leave us whiter then white little pale fishy belly looking geeks alone.

Re:Open source at it's finest

[AchiIIe]

>>Only took 15 years.

Do you even know what Real-Time computing means? Do you know what an interrupt is? Can you name even a single one RT OS ?

sigh... from wikipedia: http://en.wikipedia.org/wiki/Real-time Computing

History

The term real time derives from its use in early simulation. While current usage implies that a computation that is 'fast enough' is real time, originally it referred to a simulation that proceeded at a rate that matched that of the real process it was simulating. Analog computers, especially, were often capable of simulating much faster than real time, a situation that could be just as dangerous as a slow simulation if it were not also recognized and accounted for.

The Saturn rocket had a 50 Hz hard-coded loop.

Once when the MOS Technology 6502 (used in the Commodore 64 and Apple II), and later when the Motorola 68000 (used in the Macintosh, Atari ST, and Commodore Amiga) were popular, anybody could use their home computer as a real-time system. The possibility to deactivate other interrupts allowed for hard-coded loops with defined timing, the low interrupt latency allowed the implemention of a real-time operating system, giving the user interface and the disk drives lower priority than the real time thread. Modern Desktop PCs will usually fail at such tasks, if no specialised real-time operating system is installed. [citation needed]. The Motorola 68000 and subsequent family members (68010, 68020 etc) also became popular with manufacturers of industrial control systems thanks to this facility. This application area is one in which real-time control offers genuine advantages in terms of process performance and safety.

Real-time OS

[Hemogoblin]

I didn't know what it was either, so here you go:

http://en.wikipedia.org/wiki/Real-time_operating_s ystem

"A real-time operating system (RTOS) is a class of operating system intended for real-time applications. Examples include embedded applications (programmable thermostats, household appliance controllers, mobile telephones), industrial robots, industrial control (see SCADA), and scientific research equipment.

A RTOS is valued more for how quickly and/or predictably it can respond to a particular event than for the given amount of work it can perform over time. Key factors in an RTOS are therefore minimal interrupt and thread switching latency."

Re:Real-time OS

[mnmn]

Talk about Karma whoring.

I'm pretty sure most anyone reading this article on Slashdot knows what an RTOS is.
The remaining few know where wikipedia is

Re:Real-time OS

[novus ordo]

Realtime computing is more concerned with latency than throughput.

Re:Real-time OS

[Hemogoblin]

Only trying to be helpful. I read the article and didn't know what it was. Now people won't have to navigate away from the page to find background information. If anything, the blurb should have included a brief note as to what RTOS' are.

Re:Real-time OS

[HungWeiLo]

Don't be so sure. I've seen quite a few comments already about how "cool" and "faster" Linux will be now that it's real-time.

Re:Real-time OS

[faragon]

RTOS is all about predictability. Hard Real Time OS, such as LynxOS, VxWorks, or QNX, are able, by contract, to guarant you how many microseconds, milliseconds, or seconds you can expect for an operation to finish (as example, ethernet packet dispatching always below X ms, etc.).

Anyone with experience on unix-like RTOSes is probably glad to see RT being introduced into the main branch, as the responsiveness of a RTOS is, by far, much more satisfying. The O(1) scheduler was a nice step forward. The incoming Linux RTOS-like additions, such as preemptible kernel, priority inversion avoidment (not sure if this has been included), etc. will use few more CPU cycles and a bit less disk and I/O throughput, but will boost the user experience. This second step for introducing RT characteristics will not imply Linux becoming Hard RTOS, just a Soft RTOS. In few words: there will few changes related mainly to kernel preemption, in line with TimeSys and BlueCat Linux (i.e. adapting the RT patching to the main branch). I hope that Hard RTOS support will be added in a far future, as it involves driver architecture rewriting (the 2.4 to 2.6 it is trivial in comparison). IMO, it's worth the effort (LynxOS Posix Desktop anyone? ;-).

Re:Real-time OS

[Anonymous Coward]

A bit more about Linux and RT patches (2004).

Video playback

[teslatug]

I'm glad linux is getting more realtime capabilities, but what I wonder when will video playback not suck under Linux. Why does video playback get paused when you drag any window? Or how come you can't play two videos at the same time? Maybe these are X.org issues, I don't know, but they're annoying.

Re:Video playback

[henrikba]

I guess you should look into your configuration. I can have several mplayer windows running at once. They don't pause when I move them (allthough they morph nicely because of xgl/compiz).

Re:Video playback

[ltmon]

It's probably due to your video drivers that you see such poor performance.

With properly accelerated video playback you will have no problem. For example "Xv" playback on newer Ati cards uses hardware acceleration. Also, have a look at the XGL demonstration videos where they play videos overlapping, transparent, in the root window and deformed all at once.

Re:Video playback

[BiggerIsBetter]

Odds are you're playing through the X11 interface, when you should be using the Xv interface. Switching depends on your video player application, but most all of them can do it (with a video driver that supports Xv - most popular ones do).

Re:Video playback

[Anonymous Coward]

Mplayer + Xorg + nvidia binary drivers can play back at least 3 movies simultaneously. Open source ati driver permits only one when using Xv. You can try to work around this by playing back another movie with opengl output device (mplayer -vo gl or mplayer -vo gl2).

As for lags, videocard may be the one to blame. Once I tried to use an old PCI S3 Savage for the second display and the system was lagging even when xterm was scrolled by one line.

Re:Video playback

[Anonymous Coward]

Xv interface? What?

Is this also related at all as to why my cursor, for a very split nanosecond, jumps an inch or so from its position and then back to where it's supposed to be when I my Wacom stylus touches the pad (being in the correct position when I hover the stylus over the pad, only happening when the stylus touches the art tablet)? GIMP is the only program where this doesn't cause problems... but you see this affect drawing in oekaki applets with tons of unwanted straight lines everywhere.

Although that isn't a video-specific thing... but yeah, it sounds like there are other X clones out there that are structured in different ways? I really have never heard of Xv before.

Re:Video playback

[BiggerIsBetter]

Ah OK. Xv (short for XVideo) is part of XFree86 and Xorg et al, and it allows apps to send video directly to the display with minimal overhead. If you use Xv to play videos you get smoother playback and lower CPU usage (which you can then use for MPEG decoding, post-processing, whatever). Using "generic" X11 playback means copying lots of big image bitmaps into a window 25+ times a second, which is a lot slower.

I doubt it's related to the stylus issue, although it's been a long time since I looked at that kind of thing.

Anyways, post your system details (cpu and speed, graphics card, linux distro, etc) and I'll see if I can write something more meaningful.

Re:Video playback

[Anonymous Coward]

My system's a Pentium 4 3.2Ghz, 1.5GB RAM, ATI Radeon X800 (with latest FGLRX drivers from ati's website, Doom 3 runs like a charm), tablet is an Intuos 3, and Linux from the Slackware 10.1 distro. The only real part of my system I changed from the default Slackware distribution was the kernel, so X.org and KDE and such are as they came in the distribution. Kernel is 4.6.13, downloaded from kernel.org, and using the wacom module drivers that came bundled with that (along with modules for the 'evdev' event devices required for these tablets in Linux).

I've tried to track down the culprit of this error, but my lack of fuller understanding how windowing systems work internally is a bit of a handicap. It could be X, it could be the wacom drivers (which, as I understand, are unofficial drivers... god forbid they take a small amount of money to pay their own people to write Linux drivers for their most sought-after product), it could be the event devices... heck, it could even be KDE or even the mouse driver being confused about the existence of something else that manipulates the cursor (although why GIMP seems to not be adversely affected by this bug, while every other drawing program that isn't "aware" of tablet devices is, sort of complicates things).

Re:Video playback

[BiggerIsBetter]

You've got plenty of performance there, and FGLRX drivers support XVideo, so it should be able to play videos with ease if your play supports it too. Which player do you use? FWIW, I use FGLRX with X.org on my Radeon X1400-powered laptop and it's fine for video playback using MPlayer ( mplayer -vo xv video.avi ).

I really couldn't begin to guess about the tablet issue. If your code-fu is strong, I'd start by searching for the differences between what GIMP does and what everything else does. Might be something about GTK mouse handling that's different to other things. I realise that's not a realistic answer for most people though (either time or skills or both)... Good luck :-)

Re:Video playback

[Billnvd65]

I don't understand why you can't play two videos at once. However, as far as things like the video pausing while you move a window, check your window move options. If you select an opague window move the video will redraw as you are moving. If you have your WM set to only show the outline of the window during drags, the WM/client stops updating while you are in the click/drag mode. It however sounds like you have a bad config of your video players/video card. Like other posters, I can display several video streams at once, using several different players and drag them all around with no playback issues. I am using an ati 9600 and the stock drivers. No compiz/xgl

Re:Sliced bread next?

[Anonymous Coward]

Ever consider seeing a shrink?

Weapon change

[Anonymous Coward]

Yes, but will the new kernel reduce the weapon change delay in UT2004?

Re:Weapon change

[The MESMERIC]

I damn hope so. Otherwise I've bought the game but can't play on my ancient Dell Dimension machine :(

For Audio Work!

[reaktor]

This is good for anyone who does audio work in Linux. Until now, you had to patch the kernel to get a low-latency kernel. This is the big news- for Linux audio users!

Linux audio software will now be #1

[Anonymous Coward]

OK, this is very significant in many ways, but audio is one thing that will benefit a lot. This marks the day when Linux audio is the most viable choice for recording engineers. Projects like Ardour will offer lower audio latencies than any other system out there - including high end hardware solutions. With 1ms latency Linux will be insanely good for any kind of professional audio work.

Re:Linux audio software will now be #1

[Anonymous Coward]

Oops.. the link was broken. Ardour website. Anyway, below 1ms is not possible with any other audio system out there - and this includes Macs and Windows systems.

Re:Linux audio software will now be #1

[Overly Critical Guy]

Ha, yeah right. Linux audio software is horrible compared to the professional alternatives, and most people already have ultra-low latencies through their high-end audio hardware and provided drivers.

Wishful thinking, my friend.

Re:Linux audio software will now be #1

[Anonymous Coward]

First - let me tell you something, I'm a ProTools user. Last time I looked at Ardour I noticed it not only had all the features I use with ProTools, but some very nice new features as well not found in ProTools. I recorded 82 tracks (simultaneous tracks) demo with Ardour and everything worked very nicely. So, would you please tell me what are the features that are missing. Let's continue this discussion after that. I'm afraid one of us is audio professional and one of us is not.

Re:Linux audio software will now be #1

[DrunkenPenguin]

Hmm.. Really? Do you know what you are talking about? If what you're saying is true then I really have to wonder why high-end hardware mixer manufacturers are funding and using Ardour? These companies are one of the leading companies in the industry.

"The Ardour project is happy to be able to announce the involvement and support of Solid State Logic (SSL), one of the most respected and trusted names in the field of audio technology. SSL has chosen to support Ardour's development and to promote the idea of its broader adoption within the audio technology industry."

Solid State Logic

Harrison/GLW

Re:Linux audio software will now be #1

[Anonymous Coward]

You mean horrible compared to the consumer alternatives. It's right up there with the professional alternatives - it is a viable one. In terms of stability, configurability and ability it trumps both levels of commercial software - the only thing it's missing are the presets. If you're savvy enough, or professionally experienced in audio engineering, you'll find every tool you need, you'll route audio and control signals between them with ease, and you'll set their parameters to ear-pleasing results. If you're not savvy enough, you'll have to wait a few years for people to add a "Pop Hit Vocal" button to the screen that turns the little knobs for you. That's the only advantage commercial software currently has, and, in the professional world, where people are replacing expensive dedicated hardware, rather than Acid and GarageBand, it's nowhere near as important as stability, configurability, and ability.

Re:Linux audio software will now be #1

[norkakn]

Windows audio is pooched, but OSX's isn't. Especially under load, osx performs very nicely, latency wise.

Re:Linux audio software will now be #1

[Overly Critical Guy]

Absolutely not. Ardour tries to be a third-rate Pro Tools clone but without the hardware support, plug-ins, and other features. It comes nowhere close to a Logic Pro or a Cakewalk Sonar. Now, if you want to compare Ardour to limited consumer products like Garageband, then sure. But high-end software that the pros use in the studios? Not a chance, and if you go to a professional studio in L.A., you won't be seeing copies of Ardour running. You'll be seeing Pro Tools on Macs with Logic MIDI front-ends.

Re:Linux audio software will now be #1

[Overly Critical Guy]

Yes, I do know what I'm talking about. Ardour is a third-rate Pro Tools clone. Literally, every element in the interface is directly cloned from Pro Tools. It doesn't support the top plug-in formats, AU/VST/RTAS, and it requires going through that crappy JACK format, and there aren't alternatives for all the apps that typically interface with Pro Tools, such as Logic, Ableton Live, Reason, Final Cut Pro, etc. Ardour also only runs on Linux, and Linux consumes time like a whore consumes jizz. Pros just want to get up and running, not tinker with Ubuntu installs.

It's safe to say Apple isn't worried about losing ANY market share in the content creation industry.

Re:Linux audio software will now be #1

[Overly Critical Guy]

First off, your assumption about my level of expertise is cute.

Second, let me know when Ardour supports things like VST, AU, RTAS, Rewire, and doesn't run on Linux and that goofy JACK audio format. Also let me know when it upgrades its interface out of 1990s-era Pro Tools, since the interface is a direct rip-off, and let me know when it stops being slower than the Windows and Mac alternatives. Let me know when it interfaces with front-ends like Logic or Ableton (oh, right, Linux doesn't have them). And let me know when you can get professional technical support without resorting to IRC channels and sparse mailing list archives.

I could go on and on and on here...

Re:Linux audio software will now be #1

[Anonymous Coward]

I think you need to check your facts. It does support VST.

Re:Linux audio software will now be #1

[The MESMERIC]

I think it helps if you play with sound/media-centric Linux distros:

http://www.studio-to-go.com/
http://demudi.agnula.org/
http://ccrma.stanford.edu/planetccrma/software/

One of us, is not a audio professional. So let me make this easier for - it is not me.

Avoid non-specialized Linux distros such as Ubuntu. The average person knows fuck-all about Linux/Unix stuff, the experience will be very bitter at best. I know of a musician that broke in tears, poor thing.

Having said that - I've heard there is a distro called:

http://www.ubuntustudio.com/

Good Luck

Re:Linux audio software will now be #1

[temcat]

Ardour is backed by a major company which pays for its development: http://ardour.org/ssl_support_announcement

Ardour has VST support: http://ardour.org/node/280

(On Linux, VST support won't be 100% flawless at least in the midterm because it's relies on Wine, but when the Windows port is complete, VST plugins will be supported fully in it.)

Jack runs on Windows: http://jackaudio.org/node/13

Moreover, Ardour is currently in the process of being ported to Windows (basically only some backend details have to be ported, because all the rest, including GUI, is already portable). Also, Ardour has an OS X version, too.

Also let me know when it upgrades its interface out of 1990s-era Pro Tools

Uhm, does it need to? What's wrong with it?

All in all, it looks like you are pretty ignorant when it comes to Ardour current state. You even characterize Jack as "audio format" which makes you look seriously misinformed to say the least.

Re:Linux audio software will now be #1

[Anonymous Coward]

Ach, you are missing the point.
First, the hardware support of pro tools is abysmal. It only works with digi's own propriatory interfaces or one apogee firewire box. There is a version which is compatible with some m-audio cards, but it's limited to 32 tracks and has other restrictions which make it barely useable.

Second, plugins are not so important when you have an SSL or Harrison and a decent selection of outboard.
Forget about Sonar and VST etc, we are not talking home studio toys here.

Third, Ardour's interface is definately influenced by PT, but it's different enough so you can't really call it a clone. There are bits of Logic, Cubase and DP in there, thankfully the good bits. Think of it as combining the best parts of all the other DAWs.

Fourth, I can scrub multitrack in Ardour, and it will follow MTC properly. PT does not let you scrub more than two tracks and accurate MTC sync broke again in 7.1. I need both to work to picture. That's why most video shops are still using hardware multitracks or SADIE rather than PT.

Sure there are some compromises using Ardour, but there are compromises with PT as well.

Re:Linux audio software will now be #1

[Anonymous Coward]

Uh. I don't know anything about professional audio, but if the alternative is Mac OS X, I don't know how you can say that Linux is slow. Mac OS X (Mach in particular) has horrible latency issues.

Second... Complaining about Ubuntu's necessity for "tinkering"? I recently installed Ubuntu for someone and much to my surprise I found it was much easier to install, configure and use that say, Windows XP. Ubuntu is NOT a distribution that requires tinkering by any stretch of the imagination.

Re:Linux audio software will now be #1

[joto]

Ardour is a third-rate Pro Tools clone.

Pro Tools has been the main tool for audio professionals for decades. Sounds like a good choice if you want to clone something. I'm sorry you can't get everything you want, but even though it's third-rate, at least it's improving. And it's not like it's the only thing out there for linux either.

It doesn't support the top plug-in formats, AU/VST/RTAS

Ardour supports LADSPA plugins. It doesn't support AU because that's mac only. It doesn't support VST because that's windows only. It doesn't support RTAS because it's not an open standard, and requires special hardware. It may work with VST through wine, and if a windows or mac version is ever made, it will most likely support native plugins there.

and it requires going through that crappy JACK format

JACK is not a format. Jack is to linux what ReWire is to windows. Since jack can be used to route audio between applications, it can also be used to route audio between your soundcard and your applications. In general this gives you more flexibility. If you don't want to know this, I can write you a 2-line script so you don't need to be aware of jack. However, it will still be there, giving you more flexibility than you ever had on windows, without any loss of performance. Just because it's different from what you're used to, doesn't mean it sucks. The only thing that sucks about jack is that it doesn't do MIDI!

and there aren't alternatives for all the apps that typically interface with Pro Tools, such as Logic, Ableton Live, Reason, Final Cut Pro, etc.

Well, if you can only be satisfied by having exactly the same applications as under windows, you know where to find them. I will not dispute that linux could need more audio applications, but we don't need clones of all the above. ProTools, Logic, and Ableton Live all more or less perform the same function. They allow you to play, record, and arrange audio and midi tracks. Final cut adds video tracks. Reason has a nice selection of synths and effects. What we need under linux is tools to do the above tasks: play, record and arrange midi, audio and video tracks; create audio; modify audio and/or video. Tools should focus on those tasks, not in whether it duplicates the function of Logic or Ableton Live.

Ardour also only runs on Linux, and Linux consumes time like a whore consumes jizz. Pros just want to get up and running, not tinker with Ubuntu installs.

That kind of "pro" also has near unlimited funds and can afford to fill their studio with hard- and software for millions of dollars. Surely they can afford someone to help them inserting an ubuntu disk. As a non-pro, and from experience, I know that windows consumes a lot more of my time than linux ever has. An ubuntu install just works, compared to windows that must be tweaked for days before it works well, and must be reinstalled every 6 months. As a hobbyist musician, and tinkerer, I'd be much more interested in a home-studio running linux, than one with windows. You'd be surprised how many computer musicians agree with me.

It's safe to say Apple isn't worried about losing ANY market share in the content creation industry.

They should. Everything seems to be going windows!

Re:Linux audio software will now be #1

[Anonymous Coward]

if you go to a professional studio in L.A., you won't be seeing copies of Ardour running.

Who gives a shit what people use in L.A.? What's right is not always popular, and what's popular is not always right. Do you expect people to change their choice of software simply based on what the latest trend in L.A. might be? I mean, I haven't seen this idiotic an argument since high school.

Re:Linux audio software will now be #1

[joto]

Ardour tries to be a third-rate Pro Tools clone

I'm sure ardour doesn't try to be a third-rate ProTools clone.

but without the hardware support, plug-ins, and other features.

The hardware support isn't needed anymore. Fast multicore processors have pretty much replaced the need for specialized hardware. Of course, dedicated DSP hardware is still better, but it's certainly not the future anymore. Besides ProTools hardware is expensive, and I doubt you can get specifications for it. Besides, it's not obvious what other kinds of hardware you can use. On the other hand, software audio plugins, and support for multichannel low-latency sound-cards is there.

and if you go to a professional studio in L.A., you won't be seeing copies of Ardour running.

And if you go to a professional office in L.A, you won't see Blue Gene, you will see a DELL. And you won't see "La Modernista Diamonds" by Caran d'Ache, but a BIC-pen. Does that tell you that you something? Perhaps that proof by reference to "the pros" doesn't work?

Re:Linux audio software will now be #1

[Anonymous Coward]

Its called argumentum ad populum or argument of authority and its used (and observed) quite frequently in society. Wikipedia probably has info on 'em, as does Infidels.org at their "logic and fallacies" page.

Because video drivers are shit.

[Ayanami Rei]

I use an NVidia card with it's binary blob driver and I can play back like 8 videos at once (not very useful, but there it is)

So it's not linux itself, it's getting good drivers and making sure you use them.

lets try this again...

[j1m 5n0w]

Gleixner was the main author of Linux's hrtimer (high-resolution timer) subsystem, and has been a major contributor to Ingo Molnar's real-time preemption patch. The changelog for the 2.6.18 kernel reflects the addition of 136 patches authored by Gleixner, along with 143 from Molnar, who works for Red Hat.

The 2.6.18 release includes real-time technology that will save individual kernel developers from having to maintain separate real-time kernel trees, according to TimeSys. Additionally, embedded Linux developers or normal desktop users wishing to build kernels capable of achieving millisecond-level real-time responsiveness will no longer have to apply patches.

The article does not say what hrtimer and the real-time preemption patch actually do, nor does it say that those are the patches that were added to the kernel, merely that Gleixner worked on those as well as whatever those 136 patches are that made it into the kernel. So, what actually changed? Were internal APIs rearranged? Were long-held spinlocks replaced with shorter-duration spinlocks? Can the kernel preempt things it couldn't preempt before? Does the kernel export any new APIs to user space? What sort of improvements can we expect with these patches?

The article was quite vague in its technical details, so I was hoping someone could fill them in.

Re:lets try this again...

[Nutria]

What sort of improvements can we expect with these patches?

We, those who surf the web, play music, write email, host web servers and run databases will see no improvments.

Those who control tiny systems with ARM and MIPS CPUs will find life more consistent, because now there is The Official Real-Time Kernel, instead of a variety of non-similar patch schemes.

What does this really mean?

[otter42]

My reaction is mixed. I use RTAI in my lab, and this doesn't seem to say anything whatsoever about the technologies used in the claimed real-time kernel. In fact, from the article I don't really know if it's real real-time, or "harder but still soft" real-time. Either way, it's great that the kernel is finally seriously integrating real-time, as it's a step in the right direction for getting real-time software to work quickly and painlessly on office distros such as Ubuntu.

Anyone know if this is just the ADEOS micro-kernel patch being distributed as part of the vanilla kernel? If not, is it compatible with RTAI, Xenomai, Fusion, and RTLinux?

Re:What does this really mean?

[qbwiz]

I don't think there's a microkernel involved. The article says that the company that created this "positioned its Linux distributions as the only 'single-kernel real-time' Linux."

Re:What does this really mean?

[r00t]

I'm fairly sure this is:

1. futexes (locking for app code) with priority inheritance
2. high-resolution timers

It's progress, but not everything you need yet

[Animats]

Linux has made major progress in the real-time area. But it still doesn't have everything needed.

Many drivers are still doing too much work at interrupt level. There are drivers that have been made safe for real time at the millisecond level, but that's not universal. Load a driver with long interrupt lockouts and your system isn't "real time" any more. This is the biggest problem in practice. There are too many drivers still around with long interrupt lockouts.

The Linux CPU dispatcher is now more real time oriented. (Finally!)

Interprocess communication in Linux is still kind of lame by real-time OS standards. The tight interaction between CPU dispatching and messaging still isn't there, although it's getting better. Interestingly, it's there in Minix 3, and of course, that's been in QNX for years. For simple real-time apps, though, this may not be an issue. Generally, though, if you find the need to use shared memory between processes, it's because your OS's messaging lacks something.

While Linux has been getting down to millisecond level response, QNX has been moving towards microsecond level response. The goal moves. However, millisecond response is good enough for most applications. What really matters in real-time, though, is worst-case response, not average. Benchmarks for real time OSs put a load on the system and measure how fast it responds to a few million interrupt requests. The number people look at is the longest response time.

Despite this, Linux is probably now good enough for most real-time applications that can tolerate a big kernel.

Re:It's progress, but not everything you need yet

[The MESMERIC]

QNX speciality is real-time. Development effort is invested to keep the kernel light-years from the rest.
OpenBSD speciality is security. I wonder if every single *NIX have then their own specific niche.
Linux aims to be generic, Jack of all trades and then master of none?
I don't know you tell me. Maybe Linux wins in portability, openess, ease? popularity? It's nice to see it evolving.

Re:It's progress, but not everything you need yet

[Ingo Molnar]

Linux has made major progress in the real-time area. But it still doesn't have everything needed.

Many drivers are still doing too much work at interrupt level. There are drivers that have been made safe for real time at the millisecond level, but that's not universal. Load a driver with long interrupt lockouts and your system isn't "real time" any more. This is the biggest problem in practice. There are too many drivers still around with long interrupt lockouts.

That's where my -rt patchset (discussed by Thomas in the article), and in particular the CONFIG_PREEMPT_RT kernel feature helps: it makes all such "interrupt lockout" driver code fully preemptible. Fully, totally, completely, 100% preemptible by a higher-priority task. No compromises.

For example: the IDE driver becomes preemptible in its totality. The -rt kernel can (and does) preempt an interrupt handler that is right in the middle of issuing a complex series of IO commands to the IDE chipset, and which under the vanilla kernel would result in an "interrupt lockout" for several hundreds of microseconds (or even for milliseconds).

Another example: the -rt kernel will preempt the keyboard driver right in the middle of sending a set of IO commands to the keyboard controller - at an arbitrary instruction boundary - instead of waiting for the critical section to finish. The kernel will also preempt any network driver (and the TCP/IP stack itself, including softirqs and system-calls), any SCSI or USB driver - no matter how long of an "interrupt lockout" section the vanilla kernel uses.

Is this hard technologically? Yes, it was very hard to pull this off on a general purpose OS like Linux (the -rt kernel still boots a large distro like Fedora without the user noticing anything) - it's the most complex kernel feature i ever worked on. I think the diffstat of patch-2.6.18-rt5 speaks for itself:

613 files changed, 22401 insertions(+), 7903 deletions(-)

How did we achieve it?

The short answer: it's done via dozens of new kernel features which are integrated into the ~1.4MB -rt patchset :-)

A longer technical answer can be found in Paul McKenney's excellent article on LWN.net.

An even longer answer can be found on Kernel.org's RT Wiki, which is a Wiki created around the -rt patchset.

Re:It's progress, but not everything you need yet

[Animats]

It's painful reading how that works. It's an achievement. "613 files changed." "It's the most complex kernel feature i ever worked on." But it's one of those things that, for legacy reasons, is much more complex and ugly than it should have been.

It's sad how much effort today goes into working around bad early design decisions. After writing drivers for QNX, where drivers are just user programs with a few extra privileges, it's painful to see the contortions people go through to do them in the more primitive operating systems. The basic problem is that the original UNIX driver model was a "top part", called from read and write calls, and a "bottom part", called from interrupt level. Today, Linux drivers tend to have some threads of their own, they're loadable, and the locking primitives are better, but the headaches of the legacy architecture remain.

The price of this is that drivers remain the biggest source of OS failure. OS developers pile hack on top of hack to try to fix this, the kernel gets bigger and bigger, and it still isn't airtight. Xen and Minix3 are starting to get it right. Drivers, even hardware drivers, are user programs in those operating systems.

I know, it's not going to get fixed for another generation. QNX is going nowhere because the company that now owns it is in the car stereo business. Minix 3 is still a toy. The Hurd people totally blew it. Mach gave microkernels a bad name. But this actually can be done right, and it takes less code to do it right than the mountain of patches needed to do it the hard way.

Re:It's progress, but not everything you need yet

[CoughDropAddict]

I have the same dream you do, which is why I'm currently building on top of L4 with the intent of writing an OS that does it right. L4 is a microkernel that got it right, and makes it possible to build a non-braindead system.

I can't guarantee I can pull it off, but I'm putting a hell of a lot of time into it, and I want the results really badly. Hopefully you'll hear from me in a year or two with an exciting announcement.

Bad for windows embedded

[Anonymous Coward]

I was at the MEDC 2006 and one of the presentations was about how Linux was comparing to Windows Embedded.

We got bunch of benchmarks showing how much more consistent the kernel response time were from Windows CE (custom Kernel) versus the Linux kernel, and how -on average- the Windows kernel had shorter response time. Some people in the audience asked (more than once) if they had benchmark from the Linux kernel with the real-time patches applied ... and the answer was they were benchmarking a 'for desktop' Linux kernel versus a 'for real-time' Windows Kernel. I was expecting M$ to put biased numbers but I could not stand it and left the room after 10 minutes.

So the great thing about this announcement is that next year they won't be able to pull this off. Honestly I would not be surprised to see them use a 2.4 kernel, or show us how the stock Desktop kernel with a crap-load of unnecessary modules take so much more resources than the optimized Windows kernel.

(sorry to post Anonymously, I guess I'm a Coward)

Re:Bad for windows embedded

[LongestPrefix]

Researchers can always be sloppy, or misleading to show what they want to believe, and rarely do they even have to lie. Scientific honesty is very rare; few rise to that standard. Most would rather just publish a paper, or make a presentation, than to find the Actual Real True Facts.

proaudio cards for proaudio work

[Anonymous Coward]

If you have crappy audio hardware, you will get crappy results no matter how good the OS performs. If you are serious about audio then you will get professional audio card like M-Audio Delta series or RME Hammerfall. These proaudio cards are 100% supported in Linux and you will get low latencies. If all you need is to listen to some mp3 files then you don't really want to/need to invest in proaudio cards. It just wouldn't make any sense.

Re:proaudio cards for proaudio work

[fossa]

I have an M-Audio Delta 66 for occasional recording but mostly just music playback. I've read about others having similar problems to mine. Seems like there may be some specific issues with this card. I haven't had time to look into it too much, so I just thought I'd throw this question out there. I know there are a million variables as other replies have hinted at...

Re:proaudio cards for proaudio work

[Anonymous Coward]

2.6 Kernels support M-Audio Delta 66 out of the box. These kernels include excellent drivers for that card. What you might also want is "envy24control" application. It's a graphical frontend to M-Audio Delta series cards and is shipped with "alsa-tools" package.

Yes - media is realtime

[echusarcana]

Contrary to the reply above, the answer is yes - multimedia is one application of a usage of real time signals (a timer signal). Basically, what it boils down to is the POSIX.4 standard. In MS Windows, the multimedia timers an alternative example (I believe). On most hardware, a clock resolution of about 970us is available. So you can get scheduling with an average error of half this (so your error is half a millisecond on average).

Real time has several aspects besides just scheduling:
-real time signaling queues (e.g. timers and other interprocess signals) and other inter-process communications
-the ability to lock pages into memory
-the ability to set real time priority (pri 33-43) above the kernel (20-32) and users (0-19). To say that another way - a real time process is the king of the system.
-the ability to choose a kernel scheduling method (e.g. FIFO, round robin)
-the granularity with which the kernel can be interrupted
-the latency in switching tasks

Real time has been traditionally a concern in control system applications where predictable scheduling is important or response to a hardware interrupt must be rapid. Multimedia and many gaming applications also fit this requirement.

Real time is undermined where things like underlying hardware can disrupt predictable execution (e.g. I've seen this caused by some file system drivers). Ideally, real time applications must be designed to assume they are in complete control of the system and should not rely on the timing of any I/O activity during their execution. A real time process must sleep for anything else on the system to run. Bugs in real time applications can be very subtle to detect and may occur at low frequency.

Adding full real time support for Linux is pretty important for both usefulness and credibility.

Well, the meaning has changed somewhat

[jd]

Real-time, these days, provides a certain guarantee of service. The "harder" the real-time, the more firmly defined and the more firmly guaranteed any paramater can be. For example, you may want to guarantee that process X has a timeslice of T1 to T2 milliseconds that must start within a range of S1 to S2 milliseconds after the start of every wall-clock second, no matter what. This means if a hardware interrupt occurs that would prevent the guarantee being met, too bad. The interrupt will have to wait.

Typically, it is indeed used in simulations, but very rarely on a 1:1 simulated-time-to-wall-clock-time basis. Simulating the formation of a solar system, or the results of runaway nuclear fission cannot be done on a 1:1 basis. Instead, real-time's guarantees permit you to firmly quantify a constant ratio between wall-clock time and simulated time - provided the programmer can firmly guarantee that a given simulated time interval will never require more than a certain amount of wall-clock time to simulate and a barrier can always be established to prevent more than the desired amount from being simulated. This rules out all event-driven simulations, herustics, variable N-body problems, fixed-precision variable-mesh CFDs, etc.

As soon as the number of variables or steps becomes indeterminate for a given simulated unit of time, you cannot pre-determine the wall-clock time needed to simulate it. If, however, the guarantees are enforced, it is STILL real-time in the accepted sense, even though you have no idea prior to running the program as to when a simulated unit of time will occur. An OS does not stop being real-time if it is fed a non-computable problem, it merely stops being able to tell you when it'll get done.

ADEOS - the microkernel used in RTAI - is "hard real-time", as is VxWorks. TimeSys' Linux patches are soft real-time. Soft real-time is good for audio/video, but is pretty naff when it comes to providing any guarantees. It's usually faster than hard real-time, as it can spend more time processing than synchronizing, so is more useful on a desktop system. With suitable patches (nanosecond timers, real-time clock chip drivers, etc), Linux can be a damn good hard real-time system, but there are performance penalties. Besides, broadcast-quality images are 30 fps in the US and 25 fps in the UK. Being able to align a frame on a nanosecond boundary is thus a complete waste of time. It's damn useful if you're running a particle accelerator ring or even a maglev train (350 mph requires absolute sub-microsecond guarantees on timings), but not many home users have these yet. A pity - it might be fun to have a synchotron source.

Does Linux need hard real-time, then? Oh, certainly. It's popular in the very groups of people who are interested in nuclear science, mass transit or quantum cosmology. I firmly believe that patches that provide such mechanisms are not merely useful but extremely desirable. Bleeding-edge needs drive technology precisely because that is where technology isn't, so keeping in reach of those folk is vital.

Does Linux need real-time in the kernel? Certainly, though the soft real-time that has been added is probably sufficient. (I hate saying things like that. I'm a geek and I'm proud of it, and therefore want Linux to have the maximum flexibility possible. However, poorly maintained code is worse than no code at all, and there just isn't the userbase to keep hard real-time in the kernel at an acceptable standard.) As I said, soft real-time is all you need for multimedia. It's also all you need for games and other stuff that Linux hasn't been nearly hot enough in in the past.

Hard real-time distributions are another matter. For that matter, a distribution that provided a good set of hard real-time tools, clustering tools and CAM drivers would probably be very popular nor only with the scientific community but also with industry. A distro that pushed Linux into markets that couldn't be reached without effort from any mainstream project would undoubtedly be a good thing. It would be very much a minority effort, and yet would require far more sophisticated QA and technical support, so no sane person would attempt such a thing. Of course, I've never been accused of being sane...

About F'ing time - but BUGGY I noticed

[Anonymous Coward]

About F'ing time - but BUGGY I noticed.

cell phones

[Anonymous Coward]

No one has mentioned cell phones specifically and software radio's. Surely this is big thing for people who want to make linux based cell phones with GNU radio?

Not entirely correct.

[jd]

Those who play music will hear less skipping. Those who watch videos will see fewer frame jumps. If it was "hard" real-time, then you could guarantee that these would never occur at all, because you would be able to guarantee that the application always had the necessary timeslice to do what was needed.

For servers, real-time guarantees each process (or each thread, depending on implementation) a deterministic amount of time, so guarantees that denial-of-service to those who are currently having queries processed is impossible. (You are guaranteed your time on the server, no matter what.) However, because execution time is bounded, it also guarantees that response time can never be below some pre-defined threshold, either. A lightly-loaded machine will provide precisely the same response times as a heavily-loaded one.

For most servers, this is a pretty useless thing to guarantee - well, unless you're about to be Slashdotted. There are some exceptions. A server providing financial information would not really need to be able to respond faster off-peak, but must not fall over under stress. A networked storage device can't afford massive fluctuations in access time if it is to be efficient - mechanical devices don't have a zero seek-time. The better the device can guarantee an operation will take place at a specific time, the better the device can order events to make use of what time it has. Network routers that are hard real-time should never fail or deteriorate as a result of network congestion, it should merely hit the limit of what it can handle and not allocate resources beyond that point. (A router or switch that is not real-time will actually deliver fewer packets, once it starts getting congested, and can fail completely at any point after that.)

Real-time is not going to be generally useful to the majority of individuals the majority of the time, although it will be useful to most individuals some of the time (eg: multimedia), and to some individuals a great deal of the time (eg: those setting up corporate-level carrier-grade VoIP servers, unmanned computer-controlled vehicles, DoS-proof information systems, maglev trains, etc). All classes of user will have some use for real-time. Even batch-processing needs some degree of real-time - jobs have a well-defined start-time and must never be given so much time that the next cycle of the same job is incapable of starting on time. It's not "hard" real-time, but it's still real-time in that it is still a very well-defined set of bounds on when a process is executed and how much time it gets.

"No improvements" is therefore entirely incorrect. No noticeable improvements - maybe, depends on the situation. Some situations will improve significantly, others may actually deteriorate. No overall, on-average improvement would be closer to the truth. As for tiny systems - I run Fedora Core in full desktop mode on a MIPS, RiscOS was designed for the ARM, and I've seen plenty of embedded systems that need real-time on Opterons. For that matter, VxWorks - the "classic" hard real-time OS - is designed around the Motorola 68040 architecture and is often used by military and science labs to handle bloody huge applications (think of something of comparable size and complexity to Windows Vista as it was going to be before all the interesting bits got chopped out).

Also, when you think of "tiny systems", you generally picture something the size of a matchbox that can be powered by a watch battery. In practice, data collection systems (a heavy use of real-time) will usually use VME crates that might easily have 16 CPUs, 128-bit instrumentation busses, a few tens of gigabytes of RAM, a fan that sounds like it was pulled out of a jet fighter, and power requirements that would seriously strain a domestic power grid. The last time I saw a truly small real-time system was at a micromouse tournament, although undoubtedly there are people who use them on tiny systems. The biggest money and the heaviest demands are to be found in areas needing much bigger iron.

Re:Not entirely correct.

[Anonymous Coward]

Those who play music will hear less skipping. Those who watch videos will see fewer frame jumps. If it was "hard" real-time, then you could guarantee that these would never occur at all, because you would be able to guarantee that the application always had the necessary timeslice to do what was needed.

You can't guarantee that, unless you also lock all other tasks and their workload. This is not realistic on a desktop system, but doable on an embedded system. But you knew that already.

Re:Not entirely correct.

[Elladan]

In the long run, this is exactly what should be done on desktop systems, though. With a decent realtime kernel, it's mostly a matter of the userspace API as to whether the apps are allowed to demand realtime priorities.

For example, we could have an API that guarantees a video player realtime scheduling and all that goes with it, as long as it uses less than eg. 50% of the CPU (to prevent lockup). If the apps are then properly written (impossible for video, right now, because of the X server), then it won't be a matter of fewer skips as it is of no skips ever, under any circumstances. This is as it should be - modern computers are plenty powerful enough to give a good audio/video experience.

Re:Not entirely correct.

[Anonymous Coward]

The problem with hard realtime is that it's pretty easy to create a situation where you can't satisfy all deadlines even though the machine is not heavily utilized at all. If your user is running a media player and then tries to start a videoconferencing app and the requirements for both apps can't be met at the same time, do you prevent one app from executing or will you start missing the deadlines? The first alternative is not acceptable for a desktop, and with the second you're probably better off just using the low-latency scheduling alternatives.

Re:Open source at it's finest

[Anonymous Coward]

"Can you name even a single one RT OS ?"

Windows CE

Re:Consider this

[Anonymous Coward]

>Until kernel 2.6, Linux didn't even support multithreading.

Yes it did, you dirty homosexual.

Re:Open source at it's finest

[OrangeTide]

x86 isn't so great for real-time anyways. high interrupt latency, and pipelined architecture can make instruction latency appear random. but dang is x86 fast, but fast doesn't always make good real time. slow and steady is usually preferable. anyone can do soft real-time that's pretty easy, and pretty useful for things like embedded networking and multimedia.

I'm not sure any normal person will really care or notice the real-time stuff added to Linux. but I'm sure many companies are pleased that it has made the mainstream kernels. Usually we have to use funny extensions or patchsets.

Performance overhead of the -rt patch-set

[Ingo Molnar]

RT has a pretty big speed penalty.

I can definitely say that unlike some other approaches, the -rt Linux kernel does not introduce a "big speed penalty".

Under normal desktop loads the overhead is very low. You can try it out yourself, grab a Knoppix-based PREEMPT_RT-kernel live-CD from here: http://debian.tu-bs.de/project/tb10alj/osadl-knopp ix.iso.

From early on, one of our major goals with the -rt patchset (which includes the CONFIG_PREEMPT_RT kernel feature that makes the Linux kernel "completely preemptible") was to make the cost to non-RT tasks as small as possible.

One year ago, a competing real-time kernel project (RTAI/ipipe - which adds a real-time microkernel to 'above' Linux) has done a number of performance tests to compare PREEMPT_RT (which has a different, "integrated" real-time design that makes the Linux kernel itself hard-real-time capable) to the RTAI kernel and to the vanilla kernel - to figure out the kind of overhead various real-time kernel design approaches introduce.

(Please keep in mind that these tests were done by a "competing" project, with the goal to uncover the worst-case overhead of real-time kernels like PREEMPT_RT. So it included highly kernel-intensive workloads that run lmbench while the box is also flood-pinged, has heavy block-IO interrupt traffic, etc. It did not include "easy" workloads like mostly userspace processing, which would have shown no runtime overhead at all. Other than the choice of the "battle terrain" the tests were conducted in a completely fair manner, and the tests were conducted with review and feedback from me and other -rt developers.)

The results were:

LMbench running times:

| Kernel............ | plain | IRQ.. | ping-f| IRQ+p | IRQ+hd|

| Vanilla-2.6.12-rc6 | 175 s | 176 s | 185 s | 187 s | 246 s |
| with RT-V0.7.48-25 | 182 s | 184 s | 201 s | 202 s | 278 s |

(Smaller is better. The full test results can be found in this lkml posting.)

I.e. the overhead of PREEMPT_RT, for highly kernel-intensive lmbench workloads, was 4.0%. [this has been a year ago, we further reduced this overhead since then.] In fact, for some lmbench sub-benchmarks such as mmap() and fork(), PREEMPT_RT was faster.

(Note that the comparison of PREEMPT_RT vs. I-pipe/RTAI is apples to oranges in terms of design approach and feature-set: PREEMPT_RT is Linux extended with hard-realtime capabilities (i.e. normal Linux tasks get real-time capabilities and guarantees, so it's an "integrated" approach), while ipipe is a 'layered' design with a completely separate real-time-OS domain "ontop" of Linux - which special, isolated domain has to be programmed via special non-Linux APIs. The "integrated" real-time design approach that we took with -rt is alot more complex and it is alot harder to achieve.)

See more about the technology behind the -rt patchset in Paul McKenney's article on LWN.net, and on Kernel.org's RT Wiki.

Re:Performance overhead of the -rt patch-set

[dhilvert]

More recent PREEMPT_RT benchmarks from the I-PIPE testing team, via Paul McKenney's earlier RT overview.

Re:Performance overhead of the -rt patch-set

[Ingo Molnar]

Thanks - i forgot about these follow-up numbers that show even lower overhead for PREEMPT_RT: 0% lmbench overhead when compared to the vanilla kernel.

As a summary, i'm not all that worried about the performance impact. It is real, it will hit certain workloads more than others, but it's alot less than what was feared.

I'd still advise a generic distro against enabling it unconditionally, but a more specialized one can enable it no problem. These are the preemption kernel config options offered by the -rt kernel:

( ) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
( ) Preemptible Kernel (Low-Latency Desktop)
(X) Complete Preemption (Real-Time)

The first 3 config options are upstream already, and - as Thomas' article points it out - much of the "foundation" of PREEMPT_RT is upstream already too: generic interrupt code, generic time of day subsystem, hrtimers subsystem, the lock validator, the generic spinlock code, priority inheritance enabled mutexes, robust and PI-futexes, etc. Roughly half of what used to be in -rt is in the 2.6.18/19 kernels already.

Generic distros that want to scale from small boxes to really large multi-CPU boxes should use "Server" or "Desktop" preemption. Desktop-oriented distros could use "Low-Latency Desktop" too. Carrier-grade and embedded ones could use "Real-Time" preemption.

Re:Performance overhead of the -rt patch-set

[Nivag064]

On reading the sentence starting:
Other than the choice of the "battle terrain" the tests were conducted in a completely fair manner

The phrase
Hit me harder, Baby I'm loving it!
sprang to mind. :-)

On a more serious note, getting someone to give you some really fiendish benchmarks aimed at showing the worst performance of your software, is good value. Give's one greater confidence, than benchmarks from one's own camp.

The winners are the people who need real time - they now have better choice.

Looks like some serious heavy engineering going on in the Linux kernel, almost wish I had a reason to get into real time stuff...

-Nivag

Re:Open source at it's finest

[ThJ]

Music software on Linux will benefit from this. For software monitoring/synthesizers, extremely small sound buffers are used (128 to 512 samples). These buffers need to be refilled so often that a simple repaint of the screen or a burst of HD activity can cause clicks.

Is the -rt patchset hard-real-time?

[Ingo Molnar]

ADEOS - the microkernel used in RTAI - is "hard real-time", as is VxWorks. TimeSys' Linux patches are soft real-time.

Small correction: if by "TimeSys' Linux patches" you mean the -rt patchset that i'm maintaining (and to which Thomas is a major contributor), and in particular if you mean the CONFIG_PREEMPT_RT kernel feature, then the answer is a clear "no": it's not "soft real-time", it's intended to be "hard real-time" in the same sense as ADEOS/RTAI is.

The -rt patch-set implements a fully preemptible Linux kernel, which allows a higher-prio event to preempt any lower-prio processing: it can preempt device driver interrupt processing or other "irqs off" critical sections or other normally non-preemptible (for example spin-locked) code within the kernel, immediately. (it does all the necessary hard-real-time things one would expect: it pushes interrupt processing into special kernel threads, it implements priority inheritance for all Linux locking primitives to guarantee processing and to get out of priority inversion scenarios, etc.)

See more about the technology behind the -rt patchset in Paul McKenney's article on LWN.net, and on Kernel.org's RT Wiki. You can also try out an -rt kernel based Linux distribution yourself, grab a Knoppix-based PREEMPT_RT-kernel live-CD from: here.

Re: Change niceness

[Old Duck]

I once was about to display a video to a class I teach, but my computer I use for this was finishing a long compile (I thought it would be done in time when I started it). Of course, trying to play a video while the computer is compiling software seems crazy, but I sure didn't want to interrupt the compile process so close to being done. So, I played around with the "nice" command, and believe it or not, I was a able to give enough priority to mplayer to allow the video to play WHILE the computer was compiling WITHOUT skips!

So, look up "nice" in the man pages and give it a try. Also, I find that if one doesn't get overly gung-ho with the preemptive features of the kernel (aim for the medium preemption), things like moving windows won't "preempt" your classical music playing in the background, etc.

Hello

[illuminatedwax]

My name is Ingo Molnar. You SIGKILLed my parent process. Prepare to be made real-time.

Hard-real-time in Linux?

[Ingo Molnar]

I hate saying things like that. I'm a geek and I'm proud of it, and therefore want Linux to have the maximum flexibility possible. However, poorly maintained code is worse than no code at all, and there just isn't the userbase to keep hard real-time in the kernel at an acceptable standard.

We have good news for the geek in you: the upstream Linux kernel is already more than 50% on the way to become hard-realtime :-)

The 2.6.19-rc2 kernel already includes the following features/subsystems, which are the precondition of hard-realtime (PREEMPT_RT):

- the generic interrupt code (genirq)
- the generic time of day subsystem (GTOD)
- the hrtimers subsystem
- the lock validator (lockdep)
- the generic spinlock code
- priority inheritance enabled mutexes
- robust and PI-futexes
- SRCU
- the mutex subsystem
- irq handler prototype simplification (removal of pt_regs)
- (and more stuff that escapes my mind right now)

Most of these features were written for and prototyped in the -rt tree and were split out and merged individually. (they all have other uses besides serving a hard-real-time kernel, so their merging was largely uncontroversial)

Granted, there's still 1.4+ MB of patches pending in our 2.6.18 based -rt tree (such as the core bits of PREEMPT_RT, irq threading, high-res timers, dynticks and more), but roughly the same amount of code has been merged upstream already, and we can now see the end of the tunnel.

In fact, i'd say that the most controversial ones are already merged and the flamewars are largely over: such as the generic mutex code (which replaced semaphores half a year ago in 2.6.16/17) or the priority inheritance and rt-mutex code (which is now in 2.6.18).

Re:Hard-real-time in Linux?

[bluefoxlucid]

What I specifically want to know is what do you have left that's not in the mainline tree yet :) I can take the whole list and see what went in. Too bad my distro-of-choice won't have 2.6.18 this release; but the next release probably will be 2.6.19. I've been waiting for prio-inherit for a long, long time.. :)

What's this dynticks and high-res timers business? Is there documentation for these this time or does Redhat still go on a "write the code and some marketing" policy?

Re:Hard-real-time in Linux?

[Anonymous Coward]

In fact, i'd say that the most controversial ones are already merged and the flamewars are largely over: such as the generic mutex code (which replaced semaphores half a year ago in 2.6.16/17) or the priority inheritance and rt-mutex code (which is now in 2.6.18).

I have a question about the new mutex features: what glibc version is required to use this stuff? do I need other user space libraries?

complexity of the -rt patchset

[Ingo Molnar]

It's painful reading how that works. It's an achievement. "613 files changed." "It's the most complex kernel feature i ever worked on." But it's one of those things that, for legacy reasons, is much more complex and ugly than it should have been.

I think you misunderstood my point. The reason why our patchset is so complex and so large is because we want to do it right. The quick-and-ugly shortcut is alot smaller (and it has been done before), and it brings problems similar to the ones you outlined - but that's not the path we chose.

Here is an (incomplete) list of kernel features/enhancements split out of -rt and merged upstream so far:

- the generic interrupt code (genirq)
- the generic time of day subsystem (GTOD)
- the hrtimers subsystem
- the lock validator (lockdep)
- the generic spinlock code
- priority inheritance enabled mutexes
- robust and PI-futexes
- SRCU
- the mutex subsystem
- irq handler prototype simplification (removal of pt_regs)
- spinlock init cleanups
- spinlock debugging improvements
- voluntary preemption feature
- latency-breaker enhancements

Note that all those features originated from the -rt effort, but they have justification and use independent of real-time considerations. In other words: they make sense in a general purpose OS anyway. And better yet: our current judgement is that much of the rest is in this category too. So what we did and what we are doing are dozens of seemingly unrelated enhancements to the Linux kernel, which in the end enable hard real-time.

Is such an approach more complex instead of a quick-and-dirty hard-realtime kernel feature? Sure it is - but in my opinion this is the only way it can stay maintainable in the long run. And as a happy side-effect we'll get a hard-real-time capable kernel that will run on virtually every piece of hardware on this planet. And since we've got all the time we need and no deadlines to meet, it can and will be done =B-)

glibc support?

[Ingo Molnar]

I have a question about the new mutex features: what glibc version is required to use this stuff? do I need other user space libraries?

The latest upstream glibc version (2.5) has it:

* Support for priority inheritance mutexes added by Jakub Jelinek and Ulrich Drepper.
* Support for priority protected mutexes added by Jakub Jelinek.

(See: http://sources.redhat.com/ml/libc-alpha/2006-09/ms g00065.html )

No other userspace library is needed.

I believe so. At least, Stanford thinks so.

[hullabalucination]

So can anyone tell me if these new features would be useful for improving the responsiveness of media applications in Linux?

Well, Stanford University's Media Lab offers the Planet CCRMA Linux distro (based on Fedora Core). One of its features has been custom kernels (two "speeds," even) compiled with Mr. Molnar's real-time patch (which I think is much the same as what is being discussed in this article). Planet CCRMA terms it a "low latency" fix and it's important in certain types of audio production where you want to record a "live" track in sync with a track that's already been laid down. Too much lag in the system (just a few milliseconds) can make the whole deal unworkable when trying to do "sound with sound" recording (musicians do this a bunch). I can tell you from personal experience that Audacity's usefulness goes down a couple of notches without it. :)

You can read more about the patched kernel here, down the page:

http://ccrma.stanford.edu/planetccrma/software/ins talltwosix.html

Hopefully, this will mean that the Media Lab folks at Stanford won't have to bother to maintain the custom kernels in the near future.

* * * * *

Although golf was originally restricted to wealthy, overweight Protestants, today it's open to anybody who owns hideous clothing.
--Dave Barry

OK direction: multimedia for glasses and gloves

[Anonymous Coward]

For me, Voluntary kernel preemption and 400 Hz will be fine!!!

Why?
To imagine ...
Multimedia real-time security's factor = 400 Hz / 25 frames/s = 16 TV-quantums-like.
It's more secure than 100 Hz / 25 frames/s = 4 TV-quantums-like.

Real-time and Throughput are always in opossition, so, be careful.

Don't forget the KISS principle, don't overestimate the performance of the unknown complex algoritms like they from ReiserV4.

We need to do better the userspace fine-locks-linuxthreads-IO-schedulers source code to maximize the CPU's throughput utilization of a multithreaded process (e.x. Two Generations GCtor Concurrent MarkSweep of the High Performance JVM).

J.C.

Re:OK direction: multimedia for glasses and gloves

[Anonymous Coward]

The probability to lose the response of one frame will be high if it's playing 3 TVs.

400 Hz: security's factor = 16 / 3 = 5.33 (good)
100 Hz: security's factor = 4 / 3 = 1.33 (bad if there are locked situations)

Re:OK direction: multimedia for glasses and gloves

[Anonymous Coward]

It's easy to lose many frames responses if there are 17 active processes.

400 Hz: security's factor = 16 / 17 = 0.94 < 1.0 (oooouch!!!)

But, it's not a big problem in many desktops because, in many cases, they don't execute more than 5 active processes in the "chart of top".

Not only 17 active processes can be this a problem, with one highly locked active process can be this a problem, be careful.

J.C.

Ok, now answer me this.

[jd]

How the hell am I supposed to stay miserable and depressed if you keep integrating everything I want into the kernel? You don't make it easy on me, do you?

Seriously, this is cool stuff - I was thinking we were only going to get the earlier soft real-time stuff that I was seeing from Timesys a few years back - which was pretty good, but was not of the RTAI ilk. I don't know what you spiked their water with to get hard real-time code, but it must've been damn good stuff.

Speaking of the IDE driver...

[gillbates]

Did you ever get it fixed? If so, how?

(Disclaimer: I work with Linux in embedded multimedia players) One of the real problems I've had wrt to the IDE driver was that it would occasionally hold interrupts for 130 milliseconds! When you're playing video at 30 fps, 130 milliseconds is several frames. It creates a very difficult situation to work around.

I found a solution, but given the time pressure, was never able to formally verify it. I am kind of curious as to what you did, and if it was similar to my approach.

embedded linux os bring life to legacy hardware?

[Anonymous Coward]

I challege somebody to run comparitive test on pentium i586 hardware using embedded linux vs.blotware linux on i686 hardware. you can download the embedded linux from this site http://snapgear.org/
it would be nice to see legacy pc's running embedded linux, help save the landfills for cell phones.