Fwd: RTEMS pthreads performance (was RTEMS vs other realtimeOperating Systems ..)

[Joel Sherrill]

Kamen Penev wrote:
> 
> Joel Sherrill wrote:
> >
> > But each time we hit a new
> > benchmark comparison, there is new data to optimize against.
> 
> Apropos, are you aware of other comparison studies besides Till Straumann's
> benchmark against RTLinux and vxWorks and Greg Menke's comparison with
> LynxOS (http://that.gsfc.nasa.gov/osgroup/benchmarks.html)?

The RTEMS tmtests are themselves based upon (now ancient) published
marketing times from pSOS+.  They described their tests and we tried
to match them.  When that was done, we were performing very comparable
to them -- usually within a handful of microseconds on the same
hardware.
The hardware at that time was 16-20 Mhz 68020 class CPUs.

There are plenty of boards with networking results from the TTCP
tests.  They are normally quite respectable as well and match 
other OSes on the same hardware.

I don't know of many others.

> I think I have a reasonably good feeling about the performance of RTEMS
> (pretty darn good BTW!), but I can use more ammo to convince my coworkers.

:) Anything you find that is not right and can be identified, we will
try
to fix.  Performance is important and a continuous battle.

Most critical algorithms are constant order so that helps a lot.

> On a different note, I have managed to port RTEMS to a custom board based on
> Motorola's MPC8245 PowerPC CPU (603e core), using the psim BSP as a starting
> point. 

How different would that board be from an mpc8260ads?  That has a BSP in
the current tree.

> I am using DINK32's serial I/O routines. At this point it's not much
> more than just a hack for evaluation purposes. The CPU-related changes are
> ready for submission (basically, just another PVR value, handled as 603e), I
> think, but I need to redo the BSP, using "new exceptions" handling. Which
> leads to my second question: what are the differences between old and new
> exception handling schemes? I mean, ideologically. Perhaps this is an FAQ,
> but I could not find the answer in the documentation or in the README files
> in the source tree. Searching the archive of this mailing list was not
> productive either.

First I would love to see psim converted to the new exception processing
model.  The old exception processing model basically did not attempt to
integrate the interrupt controllers into the interrupt management.  It
treated the PowerPC as a CPU with weak interrupt skills (which it is
IMO).
But since the PowerPC is almost always tied to an external interrupt
controller,
it can be logically treated as an extension of the CPU and that is the
core of the difference between the old and new exception processing
models.

THe i386 port uses a similar approach to exceptions.  The m68k in
contrast
has enough interrupt skills in the CPU that it can handle everything 
on CPU and is simpler.  The mips port has an extended vectoring scheme
where 
a CPU model/BSP dependent plug-in routine is called to decode the vector
bits and process them.  

The old exception processing code is still in there because the 4xx BSPs
and
some 6xx BSPs have not been converted.  Converting those BSPs would be 
not only time-consuming but require testing so it has been done on a
piecemeal
basis.  I had some good news when a user of one of the 6xx old exception 
processing BSPs said they were looking at updating but that will be
after the
1st of the year if it happens.

> Thanks!
> 
> Kamen

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985