Novell to Launch Quick-Response Linux 69
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."
Quick Response and Real-Time (Score:2, Informative)
Re:from the that's-awful-fast dept. (Score:5, Informative)
This is not about the response time after you click on your Office document - and in fact, the (huge) added complexity of a RTOS is nor needed nor desired in most desktop and even enterprise uses.
Re:from the that's-awful-fast dept. (Score:3, Informative)
You might want to take a couple of computer classes before you post here again.
RTOS overhead... (Score:4, Informative)
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.
Re:Sounds like it might be (Score:3, Informative)
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 [jackaudio.org] and applications like Ardour [ardour.org] 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.
Example uses.. (Score:1, Informative)
The Passur system basically piggy backs off of the airports radar system but is in no way actually connected or related to the airports system. It is 100% passive (hence the name Passur). The unit is "synchronized" and tracks with the airports radar and reads the echoes and bounces from the planes, including the IFF [wikipedia.org] data from the planes. I believe at IAD, the Passur antenna array was at least a mile away from the airports radar too. This data is collated and sent to the airlines or airports tracking system for real time analysis of where planes are and how long until they get to some other point. The data is also sent to Passur for collection for resale to other airline related data companies or smaller airlines that do not have their own systems. The more airports and airlines they have on board using their system, the more data they have and the more useful the data is. Only one system needs to be in place to provide useful data to a much larger area. An example is the DC area, IAD radar can actually serve IAD, DCA, and probably BWI as well.
When the customer service agent at a gate announces that flight 123 will be arriving in 15 minutes and the monitors around the airport that show flight arrival times are getting that data from a Passur or similar system (or they just make up the times to shut people up).
You can obviously see that this level of synchronization requires some RT functionality and a lot of initial tuning for the timing.. The Passur system was using this back in 2000 and I have no idea what the actual state of RT Linux was back then but obviously it worked good enough. I believe the main machine was Redhat based.
One of the advanced functions of this data collection is the ability to record and "play back" what was going on in the air at a certain time as well. Their Islip facility captured the path and data from TWA flight 800 up to the point that it disappeared. I saw that played back when I was there.