Slashdot Mirror

← Back to Stories (view on slashdot.org)

Real-Time Linux Developers Unite On API

Posted by Hemos on from the agreement-is-good dept.

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.

5 of 57 comments (clear)

  1. Re:Real Time System definition by sec · · Score: 3

    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.

  2. Re:What is... by Mark+J+Tilford · · Score: 4
    Well, if you're using a text-editor, it doesn't matter whether the editor gets 10ms CPU time every 100 ms or 20 ms every 200 ms, it's the same average, as long as it can keep up with your typing. If some other program has a sudden surge of CPU usage and it doesn't get any CPU time for a few seconds, it doesn't matter.

    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
  3. Don't forget... by Shotgun · · Score: 4

    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
  4. It's basically the old POSIX real-time extensions. by Animats · · Score: 4
    This seems to be a warmed-over version of the POSIX real-time extensions, circa 1995. Interprocess message-passing operations (a classic weak point in UNIX variants) aren't taken as seriously as they are in QNX or L4. The architecture encourages putting the entire real-time application in one address space, with multiple threads. And device drivers are still part of the kernel.

    It's reminiscent of MERT, the first UNIX real-time variant, from the 1970s.

  5. Real Time System definition by sec · · Score: 5

    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.