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.
Quick-Response linux ... Whatever happened to accurate headlines
Is this RTLinux from FSMLabs repacked?
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!
With the experience they'll gather from real-time linux, may be they can fix yast which takes forever..
Novell plans to announce this product at the Gartner Symposium/ITxpo on Oct. 9
...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.
aimed at military, aeronautics, etc. But it sounds perfect for audio and video production.
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!
I'd be happy if they could just help me work out my IPv6 woes between Suse 10.0 and my ISP...
I too wonder what market they may be going after here...
Also, I wonder if this will be the usual "jack up Linux and slip a real-time kernel in underneath" approach. Then Linux actually runs as a low(er) priority task on the R-T kernel...
--- Just another Code-Monkey
Comment removed based on user account deletion
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 others) have been designing Linux to be real-time for many years now. And Novell has elaborated on that work, to provide a packaged system with a large supporting enterprise, which system is specifically designed to be capable of hard real-time operation. What's not to like? Portable code, familiar tools, free as in free... Would you rather trust a closed-source product with 10 engineers reviewing the code, or an open-source one with 10,000 engineers reviewing the code, among them, quite possibly, several of your own hires? Would you rather trust a system that has been deployed in 100 designs, or one deployed in 100,000 designs? Given the free software adoption rates in the engineering community, Linux will quickly become the latter, while QNX and VxWorks will forever remain in a ghetto.
-I like my women like I like my tea: green-
Passur makes a system system uses Linux with RT patches on the back end for the processing of radar data. About 6 years ago, I helped install and perform low level maintenance for some of the Passur subsystems at IAD for a major carrier there. I also met with and worked with the Passur engineering team near Islip airport in NY and got a day or two of technical training from them. Disclaimer: I have not worked there in over 5 years so my information may be a little out dated.
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 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.
"Real-time operating systems can respond to external events within a guaranteed time frame"
That's not really what real-time is about. Real-time is about consistent timing, not absolute timing. Thus a 100MHZ system can be more real-time than 1GHZ system.
please explain : "Novell plans to begin selling the real-time variant of the open-source operating system next month."
selling ? support or what ?
Some telephone switches could also have new operating systems installed while applications are running. Pity that most of them ran on 1970s-80s bit-slice architectures :-) And please don't insult the parent article's poster, because he's right and you're wrong....
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
"So you prefer to trust windoze?"
Sorry to break it to you, but the OS world is made up of far more than Unix/BSD/Linux and Windows.
"Like a purpose written linux/bsd etc kernel?"
No, not at all. If one were to successfully convert a non-realtime OS like Linux into a real-time one, it would essentially be a completely different OS. The same goes for Windows, BSD, UNIX, VMS, etc.
Hard realtime and safety-critical are two completely different things, althougth the latter may require the former.
Being open-source has absolutely nothing to do with my argument. In safety-critical systems, you want the entire operation of the system to be predictable. That means you might not want preemptive multitasking/multithreading, virtual memory, or really most of what POSIX offers.
I seriously doubt that "10,000 engineers" are reviewing "100,000 designs" that use Linux as stripped-down as it would need to be to really be appropriate for safety-critical systems. (I doubt that there are even 500 professional engineers who are qualified to work with safety-critical computer systems working on Linux at all, never mind 20 times that number.)
Linux is simply too complex for safety-critical systems where nearly any bugs are unacceptable. Heck, Linux hasn't even got locally-exploitable security bugs under control, never mind other kinds of bugs. Furthermore, Linux pretty much requires gcc, and gcc has bugs.
The primary advantage of embedded Linux is reduced non-recurring engineering costs, because it can do a whole bunch of things out-of-the-box that other more specialized systems can't. That's great for most cases, where occasional errors are acceptable, but it's that flexibility (resulting from Linux's complexity) that makes it inappropriate in safety-critical systems.
I haven't really used QNX or VxWorks, so I can't comment on those, but my understanding is that they're quite a bit simpler than Linux, which is a major benefit for this application. My suggestion (if you need a generic multitasking OS at all) would probably be something small like L4, with a few very well-defined tasks passing messages between each other. If you need to use Linux, run it on a separate machine that communicates with the safety-critical systems, but is not safety-critical itself.
http://outcampaign.org/
It's a hack that reserves one CPU for real-time tasks. Even the regular kernel stuff gets kicked off that CPU to make room for the real-time.
It's instead "reserve one CPU exclusively for real-time". There is no secondary kernel.
There are some crazy hacks here. Unpatched Linux will run various kernel-related housekeeping tasks on any CPU. With this, no. Other CPUs take care of the one dedicated to real-time.