inefficient RT vs efficient non-RT

inefficient RT vs efficient non-RT

[Mark Mielke]

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/

Re: inefficient RT vs efficient non-RT

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Sun, 12 Jan 2003 02:58:44 EST, Mark Mielke said:
> 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?

The question is, of course, whether you're willing to bet the entire
chemical plant on the chances of a packet being lost.

There's a difference between "if the core temperature hits 350
degrees, the pump WILL go on in 13 milliseconds" and "if the core temp
hits 350 degrees, the pump will have a 98% chance of going on sometime
between 13 and 17.5 milliseconds..."

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: inefficient RT vs efficient non-RT

[Mark Mielke]

On Sun, Jan 12, 2003 at 03:04:44AM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 12 Jan 2003 02:58:44 EST, Mark Mielke said:
> > 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?
> The question is, of course, whether you're willing to bet the entire
> chemical plant on the chances of a packet being lost.

> There's a difference between "if the core temperature hits 350
> degrees, the pump WILL go on in 13 milliseconds" and "if the core temp
> hits 350 degrees, the pump will have a 98% chance of going on sometime
> between 13 and 17.5 milliseconds..."

Of course, this is besides the original point which had nothing to do
with whether RT is better for tasks that require RT response times.

The point is that VxWorks sucks. The secondary point is that Linux may
be quite a bit more sophisticated than VxWorks. The reason for making
the point is that a guy jumped on linux-devel saying that anybody can
write a kernel, and he knows, because he has contributed to
VxWorks. He then went on to say that he has personally submitted
several dozen patches to VxWorks.

So please stop telling me what RT is and what it is best used for. I never
meant to say, nor do I think I said, that RT tasks can be 100% provided for
by non-RT Linux. If you read the posts again without this bias, you will
see that it is a stab at VxWorks, *not* a claim that RT is unnecessary.

It *is* a claim (and note the altered subject) that *anybody* can
write a crappy operating system, and people can even *sell* crappy
operating systems. I guarantee to you that I can personally write a
crappy enough RT operating system given sufficiently little time,
that Linux could satisfy 1000X the capacity of my operating system,
and running at 1X, I predict the rate that it misses on a response is
less than the rate of bugs that trigger in my code making my supposed
RT system, effectively non-RT.

It *is* a claim that Linux is not a crappy operating system.

*sigh*

mark

P.S. Don't tell me you have never heard your land line fail on you, or
     your cell phone click or otherwise. A certain amount of failure *is*
     acceptable, and in fact, unavoidable without charging you significantly
     more than what you pay for to be able to use your cell phone anywhere
     in North America, or anywhere in the world. If you paid $1000/minute,
     that would be different...

-- 
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/

Re: inefficient RT vs efficient non-RT

[Rob Wilkens]

On Sun, 2003-01-12 at 03:28, Mark Mielke wrote:
> be quite a bit more sophisticated than VxWorks. The reason for making
> the point is that a guy jumped on linux-devel saying that anybody can
> write a kernel, and he knows, because he has contributed to
> VxWorks. He then went on to say that he has personally submitted
> several dozen patches to VxWorks.

"Several dozen" per week, for two years... Totalling several hundred..
And almost none of them were in the real time subsystem because at the
time I didn't even know what reak time meant, so don't blame me for any
of that portion of the system.  I was simply working on the core
operating systems functions.

As per the OS sucking, there were a _total_ of about 10 developers on
the OS team as I recall.. From memory, Carl, Linda, Rich, Mike, Joe,
were the real time core system developers, then there was my team, the
"quality and release engineering team", which consisted of me (general
debugging), jeff (release), franklyn (nfs expert), xiaofei (not a word
of english spoken, I don't know what he did), and another robert
(genuinely good guy, scsi and general debugging expert).  So, let's
count the total number of developers that I remember: 5+8=13.  One of
which was responsible for install scripting only,  yep one guy handled
all that.  Quite impressive if you stop and think about it.  Even more
impressive is that after I quit, everyone on my team left within a year
I believe (and they were all there before I got there).  It seems I
somewhat was a motivational factor for keeping them there, though I
can't imagine why (maybe having someone near their age -- the other
development team was all older people).

Anyway, given that VxWorks is, I believe, the only o.s. that runs on the
particular NUMA hardware that it targets, or was at the time, comparing
linux to it is like comparing apples and oranges because your comparing
different hardware platforms, presumably with different speed processors
(like an old 200Mhz system which is what they were selling back in 1996
when I left to a state of the art 2.4 GHz system which they probably
sell nowadays, if not faster).  If and when Linux does run (RedHawk
linux, I'm guessing) properly on this platform, it will quickly be
modified by the real time expert there to meet the real time needs based
on the changes needed to meet their customers needs.  Of course, once
that happens, all their proprietary real time knowledge then becomes
open source....   And when I was there they had already laid off most
all of there custom hardware engineers -- so if there's not much new
custom hardware, and no specific knowledge in the software, I don't know
what the company really has to offer.. Maybe we can look for the death
of Concurrent Computer Coproration shortly after they switch to Linux...
Regardless, My point is that was a system done by about 10 people (and
we support two OS's VxWorks and CX/UX which was BSD).  If you look at
debian, it's done by "900 volunteers".

-Rob
p.s. Yes, I left out the "tools team" which had about another ten people
doing custom compilers, debuggers and that sort of thing.. And of
course, I'm only referring to the u.s. real time division of the
company.. They had a u.k. division as well which speicialized in video
on demand appplications, and they now have a headquarters wihch moved to
atlanta, only because they were displaced from ft. lauderdale by a
church when Harris (the previous company's owner) sold the building. 
The development side of the commpany refused to move, so they just went
a little (one block) north to pompano beach.

Re: RT - who cares.. (Off Topic)

[Rob Wilkens]

On Sun, 2003-01-12 at 10:05, Rob Wilkens wrote:
> On Sun, 2003-01-12 at 03:28, Mark Mielke wrote:
> > be quite a bit more sophisticated than VxWorks. The reason for making
> > the point is that a guy jumped on linux-devel saying that anybody can
> > write a kernel, and he knows, because he has contributed to
> > VxWorks. He then went on to say that he has personally submitted
> > several dozen patches to VxWorks.

By the way, I neve never said "I can write a kerenl, and I know, because
I contributed to VxWorks".. Dig back around and you'll find my exact
quote.  We're off-topic, so let's try to drop this.  I referred to an
earlier period in life when I had read two books relating to O.S.
development which probably aren't even in stores anymore because who
would buy a book on reinventing the wheel.  I only referred to my
limitted professional experience to show that I have professional
experience where I was paid to work on a professional kernel, back
around 1996-1998, when I was doing that, I don't think you could've said
that Linux was a comparable system in terms of capabilities or speed --
it's grown over time to become what it is today.

In fact, someone else looked up my background when I happenend to have
mentioned that my first gig out of college was working on OS development
for a small company in florida (the job was handed to me by my linux
kernel hacking class professor, basically --  he asked if I was
interested in moving to ft. lauderdale and gave me a busines card, I
called, went down for an interview, and took the job).  I never claimed
it was a _good_ os that I worked on, nor did I claim it was a good
company.  I'm not claiming the opposite either.  With the right staff,
any company has potential, and they hired 10 people last year for their
linux efforts (to hire anyone in this economy says something).

-Rob

RE: inefficient RT vs efficient non-RT

[Giuliano Pochini]

> 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?

Real time systems are not supposed to be faster than non-RT ones. They
just provide a reliable response time.


Bye.