OS overhead

[Joel Sherrill]

Angelo Fraietta wrote:
> 
> I have done some minor testing as I am using RTEMS as the OS for a
> musical instrument.
> My system has two boards - a PIC microcontroller for I/O and a 40MHz
> 386sx running RTEMS at 1000 ticks per microsecond.
> 
> I tested the amount of time an input went from the input of the I/O
> board, through the RTEMs system through an ISR which woke up a task, and
> back up through the I/O (I used a simple feedback mechanism). I measured
> a 3 to 4 millisecond propagation total. (the value flickered between 3
> and 4 on the oscilloscope).
> 
> I have previously measured the propagation from the I/O card to the ISR
> and measured 250us (this value therefore must be multiplied by three due
> to my inter-board communication), which means a minimum of 750us for
> inter board comms. The scanning of inputs takes approximately 2ms. The
> RTEMS overhead would effectively be > 3ms - (750us + 2ms) < 4ms - (750us
> + 2ms).

Are you doing any application data processing in that task?  
What mechanism are you using to wake up the task?  You have something
like 
this I think:

Start clock/Feed Test input
  
  ISR_Handler:
    wake up task using service X?

  Task:
     while(1)
        wait for service X
        scan inputs (3 times 750 us == 2.25 microseconds)
        write feedback to stop clock

I am having trouble seeing the breakdown between application time,
RTEMS time, and IDLE time.  I can see that the RTEMS time has
these components:

  ISR_entry
     service to wakeup Task
  ISR exit and scheduling of Task
  task switch to get to Task (probably from Idle)
  exit of blocking service in Task
  
I don't think that would be much time at all.  I would be guessing but
wouldn't think you were looking at over 200 useconds for the RTEMS
portion on the slowest CPUs RTEMS supports.   There may be more for
each of the clock ticks that occurs between the start and end of
the process but that shouldn't be more than 4 ticks with 
ISR entry, clock tick, and minimal exit.  

This whole analysis goes out the window if you have more tasks than
I think. :)  I think you have 2 ISRs (app and tick) and 2 tasks
(App feedback task and IDLE).  

FYI Greg Menke has some nice related measurements at 
http://that.gsfc.nasa.gov/osgroup/.  I think you will see that even
on a 12 Mhz R3000 MIPS, the performance is respectable.  Greg ran
a number of benchmarks and is normally quite happy to discuss things.

>From my perspective the important thing is the algorithmic order of
the operations required.  In that light, the most important places
that are of non-costant order in RTEMS are:

  + memory allocation
  + clock tick (multiple events can fire in the same tick)
  + broadcasting a message (rtems_message_queue_broadcast)

Critically, the scheduling required when a task is blocked or unblocked 
executed in constant order time.  There is a research paper on the net
claiming that RTEMS is non-predictable execution time but it was wrong.
>From what I could tell, their tool couldn't follow the use of inlines
in RTEMS and they just through up their hands and said it can't 
be analyzed.  That's wrong.  I have counted assembly instructions
in the maximum interrupt disable code fragments and can assure you that
it isn't many.  

If you know of better algorithms, please let us know.

--joel
  




> I have not done exhaustive tests yet, but I hope that this is of some
> help to you.
> 
> azzedine wrote:
> 
> >
> >Hi all,
> >
> >
> >
> >Has anybody got documentations about  overhead measurements with RTEMS OS
> >(N tasks with HPF scheduling)?
> >
> >I looking for implementations examples of real time systems with temporal
> >analysis (tasks time execution + OS time overhead), is there anybody who can
> >provide me such cases studies ?
> >
> >
> >
> >----------------------------------
> >Azzedine Abdenour
> >PH.D student
> >LESTER/Universite de Bretagne Sud
> >Lorient, France
> >
> >
> >
> 
> --
> Angelo Fraietta
> 
> PO Box 859
> Hamilton NSW 2303
> 
> Home Page
> 
> http://www.users.bigpond.com/angelo_f/
> 
> There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> There are those who seek knowledge to be known by others - that is VANITY
> There are those who seek knowledge in order to serve - that is LOVE
>     Bernard of Clairvaux (1090 - 1153)

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