OS overhead

[Angelo Fraietta]

I will explain it a bit better here, however the interaction between 
boards is quite complex so I'll make it a bit clearer

Joel Sherrill wrote:

>
>Are you doing any application data processing in that task?  
>
    Yes

>
>What mechanism are you using to wake up the task?  You have something
>
    Event

>
>like 
>this I think:
>
>Start clock/Feed Test input
>  
>  ISR_Handler:
>
            read value from I/O board storage register
           
            CASE Data
                enque data

>      Send event to input data task (only if required)
>
                send any return data (this would be the feedback data if 
any) to I/O board storage register

            CASE houskeeping
                return housekeeping data to I/O board storage register OR
                send any return data (this would be the feedback data if 
any) to I/O board storage register
           
            END CASE

>
>  RTEMS input data Task:
>     while(1)
>        wait for event
>
                    while more data
                        read data from queue                   
                        take semaphore
                        call object methods in algorithm
                        enque output for feedback
                        write notification to I/O board interface 
storage (we are not writng the data here -- only notifying that data is 
ready)
                        release semaphore

                    end while more data

>	
>
   

    I/O board // note this is a separate board not running RTEMS
        receive notification from RTEMS processor
        Read message type (this is an output data notification) (read as 
serial data from storage register)
       
        CASE data message
            write feedback to outputs (sent as serial data)
            Send housekeeping to I/O storage register (written as serial 
data)
            Interrupt RTEMS

         CASE data available
                Send request data to I/O storage register (written as 
serial data)
                Interrupt RTEMS

         CASE others
       
          END CASE 
       
       scan inputs
      
       IF inputs changed THEN
            Send data to I/O storage register (written as serial data)
            Interrupt RTEMS       
        END IF

>
>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).  
>
    The feedback is actually on a separate board running a microcontroller.
    The input data task has 2 ISRs for it, one for MIDI and another for 
other data / housekeeping
   

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

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20021126/e7b5c244/attachment-0001.html>