RTEMS Ada 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:
owneris the id of the thread that owns this period.
countis the total number of periods executed.
missed_countis the number of periods that were missed.
min_cpu_timeis the minimum amount of CPU execution time consumed on any execution of the periodic loop.
max_cpu_timeis the maximum amount of CPU execution time consumed on any execution of the periodic loop.
total_cpu_timeis the total amount of CPU execution time consumed by executions of the periodic loop.
min_wall_timeis the minimum amount of wall time that passed on any execution of the periodic loop.
max_wall_timeis the maximum amount of wall time that passed on any execution of the periodic loop.
total_wall_timeis 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 Ada User's Guide
Copyright © 1988-2008 OAR Corporation