RTEMS C User's Guide
This manager maintains a set of statistics on each period. These statistics are reset implictly at period creation time and may be reset or obtained at any time by the application. The following is a list of the information kept:
owner
is the id of the thread that owns this period.
count
is the total number of periods executed.
missed_count
is the number of periods that were missed.
min_cpu_time
is the minimum amount of CPU execution time consumed
on any execution of the periodic loop.
max_cpu_time
is the maximum amount of CPU execution time consumed
on any execution of the periodic loop.
total_cpu_time
is the total amount of CPU execution time consumed
by executions of the periodic loop.
min_wall_time
is the minimum amount of wall time that passed
on any execution of the periodic loop.
max_wall_time
is the maximum amount of wall time that passed
on any execution of the periodic loop.
total_wall_time
is the total amount of wall time that passed
during executions of the periodic loop.
The period statistics information is inexpensive to maintain and can provide very useful insights into the execution characteristics of a periodic task loop. But it is just information. The period statistics reported must be analyzed by the user in terms of what the applications is. For example, in an application where priorities are assigned by the Rate Monotonic Algorithm, it would be very undesirable for high priority (i.e. frequency) tasks to miss their period. Similarly, in nearly any application, if a task were supposed to execute its periodic loop every 10 milliseconds and it averaged 11 milliseconds, then application requirements are not being met.
The information reported can be used to determine the "hot spots" in the application. Given a period's id, the user can determine the length of that period. From that information and the CPU usage, the user can calculate the percentage of CPU time consumed by that periodic task. For example, a task executing for 20 milliseconds every 200 milliseconds is consuming 10 percent of the processor's execution time. This is usually enough to make it a good candidate for optimization.
However, execution time alone is not enough to gauge the value of optimizing a particular task. It is more important to optimize a task executing 2 millisecond every 10 milliseconds (20 percent of the CPU) than one executing 10 milliseconds every 100 (10 percent of the CPU). As a general rule of thumb, the higher frequency at which a task executes, the more important it is to optimize that task.
RTEMS C User's Guide
Copyright © 1988-2008 OAR Corporation