Red Hat juices speed freak MRG Linux Red Hat updated its core Enterprise Linux operating system stack to 6.2 in December and its Enterprise Virtualization commercial-grade KVM server hypervisor to 3.0 last week. Now Shadowman has polished up a new release of a special stack of Linux and systems software called MRG aimed at hard-core messaging, real-time, and high …
Can this kernel mod be used to control "hard" realtime systems in aviation (e.g. performing control law processing), medical systems (e.g. patient monitors) or any other kind of mechanical system which will break if the "realtime" promise fails just once ?
Or is it just a "soft realtime" system ? From my personal Linux experience I would the standard kernel less realtime-capable than Windows.
"Can this kernel mod be used to control "hard" realtime systems.."
It has some elements you'd need - but as normal you'd probably want to examine the RTOS suitability on a case by case basis.
"From my personal Linux experience I would the standard kernel less realtime-capable than Windows."
..but it's not using the standard kernel, as per the article and even the most trivial of investigation, e.g.
http://www.redhat.com/mrg/realtime/
Frankly - I probably wouldn't include it in my first list of RTOSs to consider for 'hard' RT support, and doubt i'd consider Windows at all for critical applications; you sound like you think differently so i'd be interested in hearing what you like (or not) about Windows in the RTOS context.
"Windows certainly is no "hard realtime" capable OS, but it is at least good enough to view movies properly. Something Linux seems to be challenged on occassion."
Excellent - so I was actually looking for technical feedback on something I am not well informed about, and you come back with some irrelevant drivel about watching movies. Genius.
If we look at the Financial Trading Systems where this sort of OS is used, a guaranteed latency is the name of the game.
These systems broadcast data to tens if not hundreds of clients. The AMQP message queueing software gives that sort of guaranteed low latency messaging these clients demand.
I find the comparison with other messaging systems rather funny.
Websphere MQ? Yes but only if you use the Low Latency variant.
MSMQ? Are you having a laugh?
JMS? Well, OOTB JMS is quite slow but you can use lighter weight transports so probably Yes.
Once you get down to guaranteed latencies in the low microsecond range, pretty well everything can be classed as an RTOS.
The trouble with using a general purpose OS (eg Linux, Unix or Windows) as an RTOS is that in many cases other non Real Time applications are loaded onto RT systems. When that happens, they don't become RT any more.
Then we get to RT on VM's (apart from ones that get very close to the Hardware such as z/OS & IBM pSeries LPARS) and in the Cloud. For that, all I can say is, are you having a laugh? However there is no doubt that in time that will happen.
This post has been deleted by its author
From my CS courses on RT systems I remember that "realtime" does not necessarily mean "microsecond response time". Rather, it means "well-defined time from reception of a physical event to switching to the handler task". And of course "sufficient CPU time for the handler task". Also, there were statements about priorities, the cumulative CPU time needs of processes of a certain priority and the properties you could derive from that. The "well-defined time" could easily be in the order of 20ms and that could still be called a proper, hard-realtime system if all the other conditions were met.
A hard-realtime system will assure that things like harddisk or network interface events won't break these realtime promises, even if some bozo process decides to copy 5 Gig from the harddrive to another computer over the NIC. Also, hard-realtime is incompatible with many locking architectures, as a process could own a lock which is needed to for a high-priority process to perform its work in the well-defined time amount for the application.
General-purpose operating systems often perform locking which will halt a process for reasons which are quite non-intuitive (e.g. process A halts because it hits a lock that is required by process B to update file system structures that are on a different disk).
Linux is real time enough for the London, New York and Toronto stock exchanges among others. It's also real time enough for NORAD to track flights. It's replacing operating real time operating systems like it is everything else.
Spend your time on a debatable issue, it would make comments as interesting is I hope they will be before I read them and realise what a fool I have been.
Windows in a RTOS debate?
Let me give you some examples of reasonable questions to ask.
How does it compare to the latency of VxWorks? Can Linux bring it's stability down to these devices?
What's the deal with RIM not peddling QNX to this market when it used to own it?
How does MRG compare to other RT Linux offerings such a Monta Vista's or WInd River's.
Most importantly can I use these patches to get smoother video playback on my desktop ;)
So please tell me which aircraft depends on Linux re-calculating the control laws of its software-based flight control system ?
Stock exchanges don't kill people when it takes 1 second instead of 1 millisecond once in a while to place an order. With planes or ABS brakes it is very much different.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
