RMA Analysis

[Joel Sherrill]

peter.o.mueller at gmx.de wrote:
> 
> Hi,
> 
> starting to analyze our system with RMA glasses brings up several question
> ;-) As background I red the rtems-manual and also the book "Meeting deadline
> in Hard-RT Systems" form Briand/Roy. Now I have some questions related to what
> rtems offers or better what do I need to know about rtems.
> 
> Reading the book I learned that for tasks not sharing ressources (no
> blocking) basic rma analysis as described in the rtems manual is sufficient. But for
> tasks sharing ressources blocking may occure and therefore max. blocking
> times should be included in the rma analysis. This requires that the OS is able
> to rise the priority of tasks owning
> the shared ressource dynamically to limit blocking times.
> 
> Some background info:
> - Our system architecture is that of a shared datastore. There is a set of
> data available and objects needs to read and write that data.
> - As described in the rtems manual our system consists of one critical task
> (a) which, after initialization, performs several sets of actions cyclically
> (e.g. every 100 ms)
> - An aktion (=object)  with longer run-time, runs its own task (b) with
> typically lower priority than task (a). E.g. task dealing with slow hardware
> - Obviously it is necessary to lock access to the shared datastore.
> 
> This brings me back to blocking:
> - Does rtems support dynamically rising the priority that seems to be
> necessary to limit blocking time. If not, how to deal with that?

Yes.  It supports the priority ceiling and priority inheritance protocols
on mutexes.  See POSIX mutexes and Classic API binary semaphores for
the details.

> - what is the best way to model task (a) utilizing the rma approach. As I
> understand it each action is a task in rma with cycle time, execution time ...
> - Are there papers available describing the approach to put the critical
> actions in one task? I found nothing about that in the mentioned book.

There are lots of RMA papers at CMU/SEI in their technical report library.
I recall that some old papers (1988-90) by Brinkley Sprunt have some ideas
on dealing with aperiodic things.  

RTEMS in the POSIX API also supports the notion of sporadic task scheduling.

> - Not sure what other scheduling analysis methods are there. Is there a good
> overview available?

I like a paper by Alan Burns (I think) that is an overview of real time
scheduling.
I can dig the references out of my dissertation if it isn't listed at the
University of York's site.

> - What is (your) preferred way dealing with asyncronous events (with respect
> to rma)?

The systems we have done either (1) turn then enter periodic events that
can happen with a frequency <= the period (e.g. keypresses have limit 
on frequency) or (2) make them lower priority than periodic tasks and use
a softer approach to assigning priority.  At least this way asynchronous
stuff slips when the system gets loaded.

> Comments, hints ... about using RMA in general and with rtems are highly
> welcome,

The rtmonuse code in libmisc is VERY handy even though it has some
slop in the measurements.  For each period, it shows missed periods,
min/max/avg cpu time, and min/max/avg wall time per loop iteration.  
We have not used it for heavy duty analysis in house but have used it
for SERIOUS system tuning.  Ditto for cpuuse in libmisc.

> Peter
> 
> --
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net

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