public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Mielke <mark@mark.mielke.cc>
To: David Schwartz <davids@webmaster.com>
Cc: linux-kernel@vger.kernel.org
Subject: inefficient RT vs efficient non-RT
Date: Sun, 12 Jan 2003 02:58:44 -0500	[thread overview]
Message-ID: <20030112075844.GA16050@mark.mielke.cc> (raw)

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/


             reply	other threads:[~2003-01-12  7:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-12  7:58 Mark Mielke [this message]
2003-01-12  8:04 ` inefficient RT vs efficient non-RT Valdis.Kletnieks
2003-01-12  8:28   ` Mark Mielke
2003-01-12 15:05     ` Rob Wilkens
2003-01-12 15:39       ` RT - who cares.. (Off Topic) Rob Wilkens
2003-01-13  9:38 ` inefficient RT vs efficient non-RT Giuliano Pochini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030112075844.GA16050@mark.mielke.cc \
    --to=mark@mark.mielke.cc \
    --cc=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox