Slashdot Mirror
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.
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?
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
Nature journal lied in Britannica vs Wikipedia Ask to retrac
I didn't know what it was either, so here you go:
s ystem
http://en.wikipedia.org/wiki/Real-time_operating_
"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."
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!
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.
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?
www.eissq.com/BandP.html Ball and Plate System. Amuse your friends. Crush your enemies.
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.
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)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...
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
“Common sense is not so common.” — Voltaire
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:
(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.
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.
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):
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).
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:
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-)
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:
(See: http://sources.redhat.com/ml/libc-alpha/2006-09/ms g00065.html
)
No other userspace library is needed.