Slashdot Mirror
Real-Time Linux Developers Unite On API
Markar writes "Developers and programers decided to support EL/IX by Cygnus Solutions as the API for Real-time Linux. Only one dissenter was counted after the vote was taken. The lone dissenter wanted to wait for further developements. PlanetIT is carrying more information. " You can also check out more information about the conference as well.
This really sounds like marketting hype from RedHat/Cygnus. I've heard nothing from Lineo and the other embeded Linuxes. What about Bluecat/Lynx? Where are the others? We should also remember that EL/IX was not developed as a standard Linux embeded API, but as a eCos/Linux API, eCos being Cygnus's own Free embeded OS.
Great. The realtime Linux world has settled on the EL/IX API. But what does it actually do? How does it affect the Linux kernel? Is EL/IX a library that sits on top of the kernel, or is it part of the kernel itself? Does it replace the standard system calls, or merely augment them (perhaps with calls for controlling the realtime-ness of a process)? From the point of view of an application writer, how different will an EL/IX Linux system be from regular Linux?
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Soft realtime (the announcement in the article regards hard realtime; see other comments for the distiction) generally does good enough. I'm in the habit of running my X server and window manager with realtime priority on slower machines (when I'm not doing anything else compute-intensive that I care about). It does make a big difference in that regard -- where the problem actually is CPU contention, anyway...
So, it's not a matter of starting over, just a matter of selecting another one of the existing Linux schedulers. (this operation is NOT, I repeat NOT synonymous with nice(2) -- see sched_setscheduler(2) and friends)
I actually wrote a set of tools that allow you to manipulate the realtime schedulers under Linux (soft realtime was introduced in Linux 1.3.something, if I remember correctly), and they're on freshmeat as rt-utils.
The homepage, and download links are out-of-date, but I'll get around to dealing with that soon. In the meantime, if you want a copy, drop a line to mental@rydia.net
DNA just wants to be free...
There must be an IPO involved. Every time there's an IPO involved stories disappear from Slashdot without a trace or an explanation.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
> Linux/programming/OSes etc. - but I still
> ahve no clue what the heck it is. Could
> someone please explain, in simple terms,
> what it is that all these articles are
> refering to?
A real-time operating system is one that has to respond very quickly to incoming hardware events, usually with a constraint on the maximum time alloted to complete the response. While a conventional OS (like Linux in normal operation) offers no guarantees on how quickly it will respond to requests (usually very quickly, but under high load a request could be deferred quite a while), a real-time OS usually offers guarantees on performance.
Real-time is subdivided into "hard" real-time (an absolute guarantee on system response, usually harder to accomplish) and "soft" real-time (an average-case guarantee with a certain degree of variance.)
Real-time processing is most common in things like embedded systems ("fly-by-wire" computers on airplanes, for instance, had better not take too long to process requests!), but occasionally real-time shows up in a userland/PC environment (audio processing, scientific equipment monitoring, etc.)
Hope this helps...
I keep seeing stuff about Real-Time Linux/programming/OSes etc. - but I still ahve no clue what the heck it is. Could someone please explain, in simple terms, what it is that all these articles are refering to?
-- Imagine how much more advanced our technology would be if we had eight fingers per hand.
-----------
"You can't shake the Devil's hand and say you're only kidding."
A realtime system is one where you have a fixed amount of time to deal with an event, after which the data is either useless, or something has goon wrong. For instance if you are doing audio signal processing in real time (ie, live) if you cannot generate the next output sample by the time the DAC wants it, you have to punt on that sample. In that case, losing an occasional sample is tolerable, in others, you must do *something*. An OS designed for these applications needs to have properties of bounded + known latency on every operation, and be able to guarantee that each process will be scheduled in time.
A real-time system is one that guarantees certain processes a certain amount of computation per unit of time, or that a certain process will finish by a certain time. This can be used to guarantee that a sound gets played without skipping, or that a video gets played without any pauses. People doing embedded stuff can use it to guarentee that their device does what it needs to do at the right time. Bad things can happen if an embedded system doesn't do something fast enough because of processor load. Basically, it is a system that is aware that somethings need to be done in a certain amount of time to be correct.
Fault tolerance is actually a much simpler concept than realtime, but just as hard to implement. :P
A fault tolerant system is a system in which the designers have anticipated some of the ways in which a system can fail, and designed the system to keep on functioning, at least at some level, in spite. An example of this would be redundant hardware -- if, for example, one power supply fails, the system has a backup power supply that will take over.
Fault tolerant systems are not necessarily realtime -- for example, a lot of servers have some degree of fault tolerance built in. Real time systems are not necessarily fault tolerant either, but in practice, since realtime systems are often used in places where a failure would be catastrophic (ie. the control system of an airplane) it would be a very wise idea to design some fault tolerance into them.
Now, say, that program is controlling the flight of an airplane, and the computer has to make 10 ms of corrections every second or the plane crashes.
Now, there is a big difference between getting 14 ms every second and 50 ms every 2 seconds; in the latter case it will crash, even though it gets better average CPU time. If a program other than the flight control has a burst of CPU usage....
In other words, it's more important to have a guaranteed rate of computation than a high average rate.
A real-time OS is one where a program can be started and told "Make sure this program gets at least -- CPU time every -- real time", and the OS will only run it if the program if it can guarantee giving it that much CPU time.
-----------
-----------
100% pure freak
Real-time doesn't just mean guaranteed processor bandwith. The response time is bounded. This is important.
Consider an automated assembly line application such as a sorter. A reader reads a bar code and sends a package down 1 of 10 lines. If a timer is used to control when an actuator will push the box off the line, the timer better not pop too early or the box won't be there yet.
I know this example is contrived, but it is the best I could think of in a short time. The basic point is that in a real-time OS the computer not only has to respond within a specified time, but that time is bounded so that the computer can't respond before the specified time either.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
It's reminiscent of MERT, the first UNIX real-time variant, from the 1970s.
Since some people are asking what a realtime system/OS is, here goes:
A realtime system is a system in which the response time of the system to an external event is predictable and bounded. That is, if a user presses a button, a realtime system will guarantee that the system takes whatever action is associated with that button press in a given time, or less.
This does not necessarily mean that the system is fast or responsive. For example, the design spec could say that if the user presses the button, the system must respond in 5 seconds or less. As long as the system always responds within 5 seconds, it is still a realtime system, even though most people wouldn't think of it as such.
If the system fails to respond within the specified time frame, it is considered a design failure. As such, it is used mainly in things like industrial or vehicle control systems, where failing to respond within the specified time can have catastrophic consequences.
A realtime OS is simply an operating system designed for use in realtime systems. Because of strict constraints on response times, some harsh tradeoffs must be made -- ones that users of desktop and server operating systems would find hard to fathom.
For example, a realtime filesystem is very difficult, if not impossible, to design, because some filesystem operations can have a potentially unbounded completion time. Usually, any processor cache is disabled, because, although the cache greatly decreases the average execution time, it can actually _increase_ the worst-case execution time, and it makes it very difficult to determine how long a piece of code is going to take to execute.