Metrowerks Senior Software Engineer and veteran real-time programmer Bernhard Kuhn has created a Linux kernel patch that he claims enables hard, real-time performance in the Linux kernel by adding priorities to interrupts and spinlocks. Kuhn believes his approach to be more “natural” and akin to traditional real-time operating systems (RTOSs) than the dual-kernel approach taken by real-time projects such as RTAI and RTLinux, and he is hopeful that his patch might one day win enough interest and support to become part of the official Linux kernel tree.
Linux Gets Real (-time)
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
What good, exactly, is having a RTOS as opposed to, well, whatever Linux 2.6 or Windows XP use?
The only OS I’ve tried that advertises itself as RTOS is QNX RTOS. I don’t think BeOS was a RTOS… And if it was, well, maybe that was why it was so responsive/quick?
>What good, exactly, is having a RTOS as opposed to, well, whatever Linux 2.6 or Windows XP use?
It is mostly useful for embedded products, not so much for the desktop (however QNX RtP is a microkernel and was released as a desktop product as well).
>And if it was, well, maybe that was why it was so responsive/quick?
BeOS had *initially* a microkernel-like architecture but was never a clean mk. Later in its life it was not as such at all. BeOS was responsive for other reasons: good integration between the kernel and its app_server, good scheduler etc.
Once the author’s todo list is completed, this would be great addition to the kernel. It adds some mental complexity to how IRQs are handled, but reducing the latency is worth it.
One thing I didn’t see on the todo list was an immediate port to the 2.6 kernel (which changes some things from the 2.4 series kernel). I believe this is very important.
Not only are there applications in industrial control and data acquisition but also in new sorts of Linux applications (or new capabilities for existing classes of applications).
Bravo, Mr. Kuhn.
real time should have been part of ALL OS since the bebut of that feild, right next to premptive multitasking.
the so much loved “desktop” experiance is IMHO like a patient in paralisis state that can only communicate with the real world with flashing is eyes in morse.
Interrupt should have come easily with common API, but they stayed lowlevel because at the time the “board of directors” of most company found most usefull to have accounting automated than have product fabrication + QA auto verification implemented. So company always asked for stuff like lotus and more recently office.
Because the computer industry follow fad and that university have the “brillant” idea to separate computer engineering from other engineering branch, we end up thinking RTOS is not a must have.
So, if RTOS become standard like it should always have been, having IO board (beos geekport was a step in the good direction) would be more common and we could see LOT more possibility of use to our PC’s.
BeOS was (i prefer to say is) a good “soft” realtime OS in the fact that it have the random event be them from the user or anything communicating trough the interface kit to be scheduled in acceptable time gap. It’s still good for many use but would be not responsive enough for tracking stuff faster than human movement, for that you need hard realtime.
Another good part was the media kit idea, even if it was 99% of the time associated with sound and video, those are so much extreme case that any mechanical signal could work very well with it. In fact that part is “almost” hard realtime, you can even set it so in the media pref panel. Only thing it miss is the integration of an iterrupt line for it.
beware! hard real time is not only acheiving disponibility at each given time interval, it’s also being able to not miss external signal to the computer. Sampling (polling) device at twice the max fequency of potential triggering is not sufficient.
“hard, real-time performance in the Linux kernel”
How can you achieve hard realtime, in a non predetermined configured PC ?
I thought that you had to know each and every device in a system to be able to know *exactly* when time’s up. Depending on you motherboard for example, you MMU might be slower or faster than others?
Or rather, absolutely brilliant! This is what I wanted back in 1997-98, when I set about working out the parameters for a TCAS. And of course I had to have Linux – nearly all other RTOSes were proprietary then, and that would’ve taken such a big bite out of my pocket there wouldn’t’ve been anything left. The only problem back then was that Linux itself wasn’t realtime, so I could work out what the parameters were, and how the thing should be set up, but I couldn’t guarantee anything about the timing.
Maybe I should get in touch with Bernard Kuhn, get it ported to 2.6, and get the source for all the other things that I worked out were necessary – GNATS, fping, finger, etc. I know where to get the GPS source I need now; all I need is a copy of the networking specs that the ATN uses.
You’ve made my day!
it is being applied to areas where real time systems are used and the hardware IS known.
Because the computer industry follow fad and that university have the “brillant” idea to separate computer engineering from other engineering branch…
Yeah, computer science has been downhill ever since universities had the “brilliant” idea to separate it from mathematics departments…
/sarcasm off
I can see that no one has responded to his email in kernel mailing list.
How can you achieve hard realtime, in a non predetermined configured PC ?
I thought that you had to know each and every device in a system to be able to know *exactly* when time’s up. Depending on you motherboard for example, you MMU might be slower or faster than others?
You don’t. RT systems are only useful in deterministic configurations (ie. embedded systems) where components can’t be arbitrarily added and/or subtracted to the base configuration. This patch may be interesting to embedded developers but probably few others.
It’s funny to see that Linux now also gets some kind of IRQLs – but now when they are there, the kernel could also use the levels for bug-checking (restore_flags when already running at level_zero ==> bug etc.)
“Real time” is a term referring to latencies within the system. Latency is usually taken to be a measure between the time a certain event happens, and the time an app listening for that event gets to run. Many programs, say a media player or nuclear control system, need to be run within a certain time period after an event (say, a hardware interrupt) firing. Looking at latencies, there are a few categories of OSs:
– Not real time: Win 9x, Mac OS classic, and Linux 2.4 without preemption falls in this category. In this category, latencies are complete unpredictable. In 9x, any program running 16-bit code (even 32-bit apps often had to run 16-bit OS services) could not be preempted. It could runs as long is it wanted, which makes it impossible to make guarantees. In MacOS classic, all apps were cooperatively multitasked, which meant all could run as long as they wanted. In Linux 2.4, apps were preepmtively multi-tasked, but the kernel could not be preempted, which means that any process currently executing a system call would run as long as it wanted. Because of this, maximum latencies in these systems could reach > 100ms.
Soft real time: BeOS, Win NT, Linux 2.4 + preempt, Linux 2.6, and MacOS X fall into this category. In these systems, everything is preemptible, except kernel code holding critical locks. In these systems, maximum latencies are usually less than 1.0ms. However, there are still no guarantees. It is quite possible for the latency to run a given app reach into many milliseconds. Most importantly, there is no API that allows applications to tell the OS about its scheduling deadlines, and the OS makes no attempt to make sure that apps meet those deadlines. Soft RTOSs are often very good for multimedia work, because a missed deadline means just a dropped frame or pop in the audio stream. Since missed deadlines are relatively rare, this is not a big deal.
Hard real time OSs: QNX, VxWorks, and RT-Linux fall into this category. They have APIs that allow an application to specify deadlines and latency requirements, and are architectured to have deterministic latency. They work for situations where things absolutely must happen within a certain time frame after an event fires. For example, if a temperature monitor in a nuclear reactor fires an event saying that the temperature in the core has gone above a certain level, the OS running the system must moderate the reaction to bring the temperature down. If this doesn’t happen within X milliseconds, you get a meltdown.
One interesting thing to note is that “Real time” isn’t just another word for “really fast/responsive.” A real time OS could advertise a maximum latency of 10 minutes, and as long as it exposed an API to set deadlines, and met those deadlines, it would be an RTOS. Many people involved in real time work avoided CPUs with caches for the longest time. Even though a CPU with a cache makes the average memory access faster, it eliminates determinism. A memory access when the data item is cached takes a lot less time than a CPU access when the data is not cached. They preferred a much slower, deterministic CPU than a faster, non-deterministic CPU.
Hard realtime OSs often have rather poor desktop interactivity. They must have very simple scheduling algorithms (QNX uses straight priority-based round-robin) to make scheduling predictable. On the other hand, soft-real-time OSs (Linux, WinXP, OS X, and most notably BeOS) have sophisticated heuristics in their scheduler to seperate interactive from CPU-bound tasks. This allows the scheduler to give extra preference to interactive tasks, so the system feels responsive under heavy CPU load. WinXP’s scheduler is even tied into the GUI — it gives scheduling preference to whichever app has the currently focused Window. This makes the system feel fast, but also makes it non-deterministic.
That was an excellent explanation for a clueless person like me.
I agree with you. This Rayiner guy keep posting intelligent posts all over the place, which gives extra spice to almost any topic on OS News.
Good job Rayiner, and reading about your very interesting discussion with Bascule I think it was about OS X I really digged your knowledge.
It is someone like you that would be needed for work on the OBOS kernel or at least advisor, I think you simply rock the place
What about DragonFly?
excellent discussion Rayiner Hashem, which soft-real time os is the best os?
would it be mac os x, nt, or beos?
i ask b/c there are debates about whether apple should have acquired next or beos to make os x. did they choose next b/c it is a better RTOS?
“What good, exactly, is having a RTOS as opposed to, well, whatever Linux 2.6 or Windows XP use?”
That’s for very specific tasks that are criticals on timing, so that an important thread can start at the micro-second it was triggered, and not waiting for the system to “allocate time” like traditionnal kernel/scheduler will do under Windows, Linux, OSX, etc. Not really needed for desktop use tho. You’ll find RealTime needed mostly in critical applications, like airplanes, medicals, scientific experimentations, etc.
“Hard realtime OSs often have rather poor desktop interactivity.”
I’d have to agree with this…. I ran QNX for a while as my main desktop to see what it was like. It was -great- if you only had a couple apps open, but once you got above three or so the system began to bog down. It’s not a fault, its just not designed for multi-tasking on that level. For critical systems, this would be great, and some of the code might make desktop systems perform better, but I don’t think a RT desktop system would fit what most of us want. I do have to applaude this man for his hard work, and hope many good things come of it.
“Hard real time OSs: QNX, VxWorks, and RT-Linux fall into this category. They have APIs that allow an application to specify deadlines and latency requirements, and are architectured to have deterministic latency”
Except for VxWorks Priority inversion bug
@Brian
IIRC, it wasn’t a bug, but more a matter of a bad configuration. VxWorks supports priority-inheriting semaphores, but they are off by default. The NASA engineers forget to turn them on.
@XBe
Thanks for the compliment
@Anonymous
I don’t know the latencies of WinXP’s kernel, but I’ve heard great things about OS X’s CoreAudio architecture. BeOS had any extremely low-latency kernel for its time, but its been eclipsed since then by both OS X and Linux.
>> I ran QNX for a while as my main desktop to see what it >> was like. It was -great- if you only had a couple apps >> open, but once you got above three or so the system >> >> began to bog down
It’s not that the system bogs down, its that the default scheduler doesn’t work like a UNIX or Linux scheduler.
I have no proof, but I belive that if done correctly, you would see better performance out of a RTOS than an OS with no determinism. It’s much easier to optimize algorithms when you know *when* they are going to run.
I must mention that Nucleus RTOS by Mentor Graphics is the best. They even give you the source code royalty free when you buy a license.
Nothing beats that, not even Windriver…
I read through the comments here but I don’t understand why people are so happy about something that existed for very long time. A company I’m working for is using TimeSys Linux RTOS (full version) and apparently it has very little changes from the GPL TimeSys Linux kernel which is now corresponds to version 2.4.21. What they claim is that average reliable time for operation responce is <50 micro seconds in GPL version and <10 micro seconds for their proprietory RT version of Linux. So even their GPL version will be “good enough” for most projects that need reliable control of time.
Enjoy.
It’s about time. Great job.
OS X/Darwin/BSD should have that too, by the way. Anyone doing that port?