“A well-illustrated technical paper comparing RTLinux, RTAI, and VRTXsa has been published by two Italian computer science students. Emanuele Mattei and Andrea Ludiciani conclude that the RTOSes offer comparable predictability, while RTLinux is the least variable and RTAI the most efficient.”
The Authors did a pretty good job of presenting their case. Their conclusions are generallly in-line with what one would expect. The only negative is that they used a ‘dead’ RTOS for their comparison, VRTXsa. Though still around, I don’t believe it’s actively developed. A better comparison would have been against a recent version of VxWorks, and then throw in QNX just to give micro-kernel a crack at it.
I’ll need to re-read this again, as I’m looking into the possible integration of a real-time Linux kernel for our products at work.
Linux has come a long, long way in this area. If you read Robert Love’s discussion of the 2.6.x process scheduler in his Linux Kernel Development book, you’ll likely come away thinking it’s a clever design. But that discussion doesn’t even touch on the embedded space, and it hardly mentions huge systems.
The magic is that the same scheduling framework that makes desktops snappy also consumes very little CPU time (especially in interrupt context) for embedded applications, while also supporting hierarchical scheduling domains for huge systems. While other modern UNIX implementations have stuck with traditional two-level dispatcher/scheduler setups with fixed timeslices, Linux has come up with an innovative approach that scales up and down with ease.
I’m not sure the desktop/server Linux 2.6 scheduling framework or preemption is being tested here.
The RTLinux kernel runs a 2.6 kernel as a lowest priority thread, and intercepts all hardware interrupts. It handles the high priority threads and has it’s own scheduler.
Ie, Linux is being run as the idle task of a real time OS. RTAI works in much the same way.
Linus’s 2.6 Linux was never intended to be hard real time, and probably never will be. The intelligent task/io schedulers that make a great desktop OS are not desirable in a hard real time deterministic OS.
1) Lots of peripherals are supported by Linux
2) Once the hardware platform is running Linux, you have a platform that lots of developers know how to write code for.
Raw performance isn’t as important as time to market and developer resources. It’s that simple.
The article was about real-time usage, so your comments are a bit off-topic: even though lots of peripheral are supported by Linux, not all these drivers are ‘real time ready’.
What I find weird in the paper is page 13:
“RTLinux isn’t affected by the stress increment and it would have the lowest variation if we don’t consider a peak around 53k nanoseconds. This peak is a unique event and may be ignored as an anomaly.”
Real-time is about predictability so these kind of ‘unique event’ should be investigated, not ignored!
Raw performance isn’t as important as time to market and developer resources. It’s that simple
To clarify: Raw performance isn’t as important to manufacturers as time to market and developer resources. It’s that simple, time is money. For consumers, performance is a much bigger issue.
Of couse, there is the argument of number of features vs. performance. But there is a tendancy in the industry to over-provide on the featureset front.
When I saw in conclusion they said that linux wasn’t the best I was thinking about how much time I should wait before some linux users says that linux is the best nonetheless.
I haven’t to wait so long ….
Didn´t you read the paper?
It seems generally clear that linux systems are more performing considering efficiency while VRTXsa has the less perturbed graph. It seem evident that linux systems are the best choice considering the following facts:
– maximum efficiency values are always lower than VRTXsa minimum values
– linux based systems peaks are more frequent but more modest than VRTXsa ones
– VRTXsa in ipc tests has the advantage of managing a quarter the data linux manages (4 bytes against 16)
Considering all these facts and what analysed previously, it seems that linux based systems are the best solution and that such systems can be a valid and more efficient alternative to VRTXsa. Therefore would be
surely advisable a migration from VRTXsa to a linux based real time system.
Edited 2007-01-31 08:52
Don’t bother – of course he didn’t read the paper. I t would be a waste of time, if all you want to do is troll…
Well, it’s hard to beat its features/price ratio.
You mean its features/bugs ratio.
Hi all,
we are the authors of this paper.
First of all we wanted to thank everyone interested in our pubblication.
We want also clarify that we didn’t exactly choose VRTXsa . The goal of the project was to migrate a tlc board from vrtxsa to a linux-based system. So it was important to evaluate the differencesbetween this system and the linux-based system we choosed (RTLinux and RTAI).
Sincerely,
Emanuele Mattei
emanuele[dot]mattei[at]tiscali.it
Andrea Iudiciani
andrea[dot]iudiciani[at]gmail.com