Linux is perfect as a hard real-time OS. Consider, for example, Gene Kranz in 1969.
Apparently, “During descent, the Lunar Module’s computer was unable to keep up with the data stream from the landing radar, a non-critical task.”
An interesting definition of “non-critical.”
I suppose anybody can shill themselves out on the basis of fifteen years’ “experience” in real-time, but you’d have to think that they’re not so ignorant about their basic trade (one would assume that to be “real-time”).
Well, there’s always the Exercise For The Reader. See if you can spot the RTOS fallacy embedded in the following quote:
“We can then use a soft real-time task which will on average have the required throughput and low enough latency to process the buffer stored by the hard real-time task. We know that we will keep up with the data stream which has been safely stored for the soft real-time task even though we may not be able to guarantee we get to each and every sample before the next comes in.”
Clue: amongst other things, you might want to ask what “average” means.
Comments
“The line between what is real-time and non real-time appears to be a moving target.”
It’s a moving target so as long as you move it hard enough. We are talking about an art that Linux advocates have already perfected since the 90s, so I don’t really see anything surprising there.
“Hard real-time is an absolute deterministic response to an event. It is not based on average response time”
Well, when you say “deterministic”, I think you mean as in “the difference between a deterministic and a non-deterministic Turing machine”. But whey you say “average”, then I really have no idea what you are getting at. Yes, the rules within a soft RT system can be flexible, but never to the extent that it just keeps failing to meet deadlines. In other words, there are always bottom-lines to be met, not “turtles all the way down”, as some might say.
“Embedded systems come in many flavors, each with different requirements. Real-time performance is as diverse as the flavors of the applications the underlying RTOS is asked to serve, and no RTOS can fit all applications.”
That depends on what really qualifies as an “RTOS”. Linux, for one, simply doesn’t cut it in any sense. And you point is?
“Examples of these sorts of real-time system include streaming audio and video where large buffers are put in place to minimize “drop outs” and where occasional buffer under/over runs are non-fatal.”
No, I suppose you can’t really consider the inability of watching “Hamster on a Piano” at above 2 frames per second as fatal, but that’s still pretty underwhelming as far as video streaming is concerned.
By the way, in case you are still wondering who the Blake Stowell is, he is currently the PR director of Omniture Inc. and has once been the “corporate communications” director at SCO group. Just think of him as the IT version of Baghdad Bob – if you get my drift.
“With this in mind, we can start to define what we mean by hard real-time and soft real-time, and it’s startlingly simple. In a hard real-time system, the deadlines are fixed and the system must guarantee response within a fixed and well-defined time.”
No, that’s the expected behavior of ALL RT systems, hard or otherwise.
“In a soft real-time system, we take a best effort approach and minimize latency from event to response as much as possible while keeping throughput up with external events overall.”
Wrong again! A system that fails to give you a predictable sampling rate is simply NOT a real-time system. Just picture in your heads a satellite broadcast of a live sporting event arbitrarily dropping frames as it went. Heads would be rolling, jobs woulds be lost, and the world as we knew it would END!
Now, if you have never heard the name “Jeff Dionne”, he is the co-founder of project “uClinux”, a patently freetarded substitute for the Apple iPod OS. That’s right – the guy who actually wrote the article has exactly jack squat to do with RT systems, which on average translates to 0/0 = NaN experience in RT computing, but, on the bright side, he can probably go and form a comedy duo with Blake Stowell and blow Flight of the Concords out of the water.
“But if we look at Gene’s definition, we see that this really is a red herring.”
Not as much as this article is one.
“But back to OSes, and specifically RTOS definitions. From all of this, it’s clear that a hard real-time OS is one that provides a guarantee that the response to an event will occur within some fixed time, without fail no matter what.”
Let me repeat this again for you – the same rule goes for ALL RT systems, hard or otherwise. There is a gaping difference between taking samples at a predictable intervals and spontaneously losing samples due to insufficient buffer memory. Fudging the line with this kind of cretinous arguments simply does not an RT system make.
“We can use a hard real-time task to read the converter into a buffer in memory, safe in the knowledge that no matter what other demands are placed on the system, even ones that where unforeseen when the system was designed, every sample will be read from the converter into a memory buffer.”
... And then we just discard said data in some utterly unpredictable fashions and thus completely negate the reason to have a real-time component in the system in the first place.
“Finally, we can take the post-processed data from the soft real-time task and display it on a console of some kind.”
If it’s a video, then it will be guaranteed utterly unwatchable. If it’s experimental data, then it will be the greatest scandal in the scientific community. If it’s a security alarm for a missile silo, then be prepared for the friggin’ Armageddon.
“Linux based RTOS solutions are available for all of these classes of system — accommodating simple problems requiring a few milliseconds average soft real-time response”
Again, the word “average” here simply doesn’t cut it. People need to know when the sampling takes place and how much data is lost in the transit. That’s basically what every real-time systems, digital or analog, dynamic-rate or otherwise, need to make clear in their specifications. Your argument sucks at being one and you aren’t an RT system developer in any sense. Get lost.
What you said.
Thanks for the bios, btw — I’m not dedicated enough to check out each and every loon out there.
I’m not sure that this even constitutes FUD, as opposed to bare-faced incontinent lies. I think you nailed it with the quote “Real-time performance is as diverse as the flavors of the applications the underlying RTOS is asked to serve, and no RTOS can fit all applications.”
Really? I’ve yet to see a RTOS that doesn’t fit 99%+ of RTOS applications.
But to be fair to Linux, there are a couple of those out there. Thing is, they’re stripped down and proprietary and might as well be entirely separate OSes. Even then, I’d rather use an OS built for purpose.
(I also got yelled at by Kharkhalash — justifiably — for dissing audio and video latency as “not real-time.” Well, of course they are. They’re just not related to RTOSes, as K himself has previously pointed out.
(The sad thing is, Linux can’t even manage this approximation of an RTOS.)
You sure this isn’t Oiaohm back at his RT rantings from last year? Those were quite fun.
“Real-time performance is as diverse as the flavors of the applications the underlying RTOS is asked to serve, and no RTOS can fit all applications.”
Stowell concludes with:
“By meeting such a broad range of system requirements, Embedded Linux comes very close to being a universally applicable RTOS.”
It’s too bad he left the contradiction to the end. I want those 5 minutes back.
Ah, but it’s not a contradiction.
In the Land of Loon, “nowhere near, by definition” is identical to “very close, if you ignore the definition.”
It’s just like marketing, only stupider.
You must be signed in to leave comments.