Slashdot Mirror
Novell to Launch Quick-Response Linux
Krishna Dagli writes to mention a C|Net article about Novell's upcoming real-time Suse Linux Enterprise product. From the article: "Real-time operating systems can respond to external events within a guaranteed time frame, a feature that mainstream business computing doesn't generally require but that's necessary for some areas, such as aircraft radar. But in a move that indicates the flexibility of Linux, Novell plans to begin selling the real-time variant of the open-source operating system next month."
from the that's-awful-fast dept.
It could take me a week to respond. As long as I respond within that week and a week is all that's needed, I'm realtime.
Realtime is not about speed, it's about fixed time intervals.
Max Power: Kids, there's three ways to do things. The right way, the wrong way, and the Max Power way!
Bart: Isn't that the wrong way?
Max Power: Yeah, but faster!
Hint: If you actually read the article, it will answer your question.
...are not related. Real-time operating systems have shadulers that sort tasks per various priorities. Which mean that task admitted with low priority isn't going to have quick response.
Give me a break here. Novell is (Barely) known as an enterprise back office company. They make awesome management products, have a decent linux distribution, and a load of magic glue to hold all that together.
Where in the world does aircraft radar and embedded manufacturing fit into that business model? Is Novell hiring it's competitors to do marketing for it? Eesh!
A characteristic common of multi-tasking RTOSs is that timeslices are very small, and context switches extremely frequent, to help assure that apps will be able to do something in the required timeline, which is not necessarily a small amount of time, but in many applications it is a short time. There are more complexities, but the bulk of the 'overhead' mentioned in the GP is probably the high percentage of time spent doing context switches rather than useful work. The key word here is multi-tasking RTOSs, you describe cases in which the OS is largely a base for a single application that does everything itself. This is very common in the RTOS world, but their do exist areas where pre-emptive multi-tasking RTOSes fulfill a need....
Of course, your point is correct too, a requisite step with respect to this particular aspect of a RTOS is generally considered to be doing whatever it takes to make the context switch as fast as possible. In a server or desktop OS historically context switches aren't nearly as optimized as the solution can be for most applications to lengthen the timeslice. Server platforms particularly tend to have long timeslices as their activity isn't highly interactive, and the percentage of the time the system can do useful work is more important than each application being able to do their thing in a timely manner. On a desktop OS, timeslices being shorter is helpful (fairly recently a lot of debate and configurability happened in linux with respect to this), as multiple applications are more directly interacting with users. With a handful of processes it isn't really noticeable but as it scales up the delays get into perceptible fractions of a second. Having a smooth interface is a bit more along the lines of a design point of RTOS, so it makes sense. Anyway, there is a penalty paid, but the timeslices for satisfying human interaction requirements may still be orders of magnitutde higher than those required for RTOS applications, depending on what's going on.
XML is like violence. If it doesn't solve the problem, use more.
Ingo Molnar and Andrew Morton's original 2.4 patches for better soft-real-time performance were prompted by complaints from those of us in the linux audio (pro-audio/music) software community. Systems like JACK and applications like Ardour were written around this kind of functionality.
Ingo has picked up the ball and run with it for 2.6 to the point where a kernel patched with his most recent patches is basically hard-time except for cases where a badly written device driver screws it up. And increasingly parts of his work have become part of the vanilla kernel so that even a 2.6 kernel now works pretty well unless you need very low latency (as require for real-time monitoring and FX processing.