Howto measure system load

Christian Walter wrote:
> 
> Hello,
> 
> I am currently looking for a solution to measure the application load on 
> my embedded system. An approach I though about was hacking the RTOS I am 
> using and every time the idle task is scheduled I count up the time in 
> this task for a given time frame (e.g. 1 second). Having finished that I 
> could use the accumulated time to calculate something like a system load 
> with:
> 
>  load = ( TOTAL - ACCUMULATED ) / ( TOTAL )
> 
> The drawback with that is that I need to hack the scheduler. Are there 
> any better options for that? Specially I am looking for options where I 
> don't need to hack the RTOS.
> 
> Kind regards,
>     Christian Walter
Look up
Emmbedded System Design  June 2006
Jack Ganssle "eXtreme instrumenting"

One suggestion was to find an extra I/O pin, Raise it at the beginning 
of the idle task and dropping it at the end.  Then hook the pin to a 
scope or analog meter.

  Good article.

Christian Walter wrote:
> Hello,
>
> I am currently looking for a solution to measure the application load on
> my embedded system. An approach I though about was hacking the RTOS I am
> using and every time the idle task is scheduled I count up the time in
> this task for a given time frame (e.g. 1 second). Having finished that I
> could use the accumulated time to calculate something like a system load
> with:
>
>   load = ( TOTAL - ACCUMULATED ) / ( TOTAL )
>
> The drawback with that is that I need to hack the scheduler. Are there
> any better options for that? Specially I am looking for options where I
> don't need to hack the RTOS.

This may measure overall system loading.  But remember that in a real-time
embedded system, the overall loading is only one aspect of how close you are to
running out of time.  Your processor can be idle for over 50% of the time and
still fail to respond to an external event in a timely manner due to too many
demands being placed on the CPU at the wrong time.  Overall loading is fine for
systems where all exteral events are buffered, but it means little on a system
with real-time requriements.


Robert Scott
Ypsilanti, Michigan

Christian Walter wrote:
> 
> Hello,
> 
> I am currently looking for a solution to measure the application load on 
> my embedded system. An approach I though about was hacking the RTOS I am 
> using and every time the idle task is scheduled I count up the time in 
> this task for a given time frame (e.g. 1 second). Having finished that I 
> could use the accumulated time to calculate something like a system load 
> with:
> 
>  load = ( TOTAL - ACCUMULATED ) / ( TOTAL )
> 
> The drawback with that is that I need to hack the scheduler. Are there 
> any better options for that? Specially I am looking for options where I 
> don't need to hack the RTOS.
> 
> Kind regards,
>     Christian Walter

Hello again,

I just wanted to thank everyone who proposed solutions for my problem. I 
found some more time today to try some of the suggestions and wanted to 
let you know about my solution (Basically based on the ideas from Mike 
Silva and others).

  * I created a free running counter where I know the number of ticks
    within a given time interval.

  * I created an additional task in the system which has lower priority
    than all the other tasks.

  * This tasks periodically checks if there was enough time between
    the last calculation and now (for averaging). If the time has
    passed the load is calculated by

    ucLoadEstimate = ( unsigned char )
      ( ( ( ulDeltaTicks - ulIdleTicks ) * 100UL ) / ulDeltaTicks );

    where ulDeltaTicks is the time between the calculations and
    ulIdleTicks is the number of ticks successfully monitored in
    this task by a busy loop.

  * The term "enough time" refers to the variable ulRequiredTicks
    which in my case is calculated from the timer frequency and
    was chosen to match one "real" second.

  * The counter is monitored continuously and if changed the value
    of ulIdleTicks is incremented.

For reference the relevant parts of the code are shown below. The 
meaning of the defines should be clear from the context.

do
{
   ...
   ulCurrentTick = TIMER_VALUE(  );
   ulDeltaTicks = ulCurrentTick - ulLastCalcTick;

   /* If enough time has elapsed try to estimate the load. */
   if( ulDeltaTicks > ulRequiredTicks )
   {
     ucLoadEstimate = ( unsigned char )
       ( ( ( ulDeltaTicks - ulIdleTicks ) * 100UL ) / ulDeltaTicks );
     ulIdleTicks = 0;
     ulLastCalcTick = ulCurrentTick;
   }
   else
   {
     /* If the timer has changed we monitored the event. Therefore
      * is is likely that the processor time was spent in the idle
      * task. */
     if( ulCurrentTick != ulLastTick )
     {
       ulIdleTicks++;
       ulLastTick = ulCurrentTick;
     }
   }
} while( 1 )

Kind regards,
	Christian Walter

Sandeep Dutta wrote:

> > I am sorry but I do not understand the solution. An idle task hook is
> > already available in the OS but how can I measure the time within this
> > task. Counting the number of times the task has been scheduled is
>
> I think the idea is to measure the "time" spent in the "idle" task not
> how many times it got scheduled. Since you mention the OS provides a hook

The canonical way to do this is to set a GPIO on entry to the idle task
and clear it on exit. Connect a voltmeter to the GPIO. You get a "PWM"
system load indicator. Vcc=no load. 0V=saturated.

On 2 Oct 2006 02:37:12 -0700, larwe <zwsdotcom@gmail.com> wrote:
> 
> Sandeep Dutta wrote:
>> > I am sorry but I do not understand the solution. An idle task hook is
>> > already available in the OS but how can I measure the time within this
>> > task. Counting the number of times the task has been scheduled is
>>
>> I think the idea is to measure the "time" spent in the "idle" task not
>> how many times it got scheduled. Since you mention the OS provides a hook
> 
> The canonical way to do this is to set a GPIO on entry to the idle task
> and clear it on exit. Connect a voltmeter to the GPIO. You get a "PWM"
> system load indicator. Vcc=no load. 0V=saturated.

Ooog. You could then connect _that_ pin to a resistor and capacitor pair
chosen to match a given measurement period (e.g. "What's my system load,
averaged over ten seconds?").

Taking this one step further, you could hook the output of this integrator
to an A/D input pin on the same controller for logging purposes. <grin!>


Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut minds pring dawt cahm (y'all)
--
    Sacred cows make the best hamburger. -- Mark Twain
--