lkml.org 
[lkml]   [2003]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectinefficient RT vs efficient non-RT
On Sat, Jan 11, 2003 at 11:09:13PM -0800, David Schwartz wrote:
> No, I've never used vxWorks, I just understand the difference
> between an RTOS and a non-RTOS and how to choose the right tool for
> the job. If an application can run on an OS that is not an RTOS, it
> almost always does. RTOSes are usually used where you *must* *have*
> guarantees.

The parts that you are not considering are:

1) Many RT applications only need a small portion of RT.

2) VxWorks adds a much more significant hit to performance that many
consider to be reasonable. In fact, the hit is such that given the
*SAME* capacity requirements, there is evidence that non-RT Linux
can be sufficiently faster than RT VxWorks that 99.999+% can be
'guaranteed' and still have time to spare.

I'm talking actual experiments by actual RT application designers. The
product in question, I believe, is a CDMA cellular telephone switch.

You are talking theory from a text book. I'm talking practice from people
who are frustrated with VxWorks on a daily basis.

Don't assume that because it has 'RT' on the label, that it makes it
beyond comparison with a non-RT operating system. Any operating system
can be poorly written, and that includes RT systems that successfully
guarantee system calls to require a fixed amount of time to
complete. The fixed amount of time to complete may be fixed, but it
may also be unreasonable high.

Think about it logically -- if I can process 5X as much data as you can on
the same hardware, but I can't guarantee that *at* 5X no data will be lost,
but then, I only run at 1X (the same speed as you), how many packets have
a chance of being lost?

In theory, a few, perhaps more. In practice, it's really hard to say,
and I trust experimental data from my peers over theory from
you. Sorry. :-)

When you've run your software on VxWorks, and then run your software on
Linux, and you have numbers (experience + numbers vs theory) then I'll
take your word over theirs.

Until then, I don't plan to touch VxWorks. I much prefer encouraging
Linux+RT to out-perform VxWorks, and be able to prove it. (For all I know,
they may have done this already -- from what I have heard about VxWorks,
it can't be that hard...)

mark

--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.049 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site