Linked by Thom Holwerda on Tue 30th Jan 2007 23:28 UTC, submitted by anonymous
Talk, Rumors, X Versus Y "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."
Order by: Score:
Fairly Decent Review
by EmbeddedGeekSDB on Wed 31st Jan 2007 00:40 UTC
EmbeddedGeekSDB
Member since:
2006-06-17

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.

Reply Score: 3

RE: Fairly Decent Review
by butters on Wed 31st Jan 2007 05:18 UTC in reply to "Fairly Decent Review"
butters Member since:
2005-07-08

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.

Reply Score: 4

RE[2]: Fairly Decent Review
by philicorda on Wed 31st Jan 2007 22:14 UTC in reply to "RE: Fairly Decent Review"
philicorda Member since:
2005-12-31

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.

Reply Score: 4

Compelling reasons for choosing Linux
by ntl_ on Wed 31st Jan 2007 03:12 UTC
ntl_
Member since:
2005-07-09

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.

Reply Score: 4

renox Member since:
2005-07-06

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!

Reply Score: 5

stestagg Member since:
2006-06-03

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.

Reply Score: 1

v lol
by Duffman on Wed 31st Jan 2007 07:48 UTC
RE: lol
by NxStY on Wed 31st Jan 2007 08:51 UTC in reply to "lol"
NxStY Member since:
2005-11-12

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

Reply Score: 5

RE[2]: lol
by Moocha on Wed 31st Jan 2007 21:40 UTC in reply to "RE: lol"
Moocha Member since:
2005-07-06

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... ;)

Reply Score: 1

RE: lol
by shiny on Wed 31st Jan 2007 09:06 UTC in reply to "lol"
shiny Member since:
2005-08-09

Well, it's hard to beat its features/price ratio.

Reply Score: 1

v RE[2]: lol
by Duffman on Wed 31st Jan 2007 12:07 UTC in reply to "RE: lol"
Some explanations about this paper
by Lele79 on Mon 5th Feb 2007 09:56 UTC
Lele79
Member since:
2007-02-05

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

Reply Score: 1