Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > T&M

How to calculate CPU utilisation

Posted: 02 Aug 2004     Print Version  Bookmark and Share

Keywords:CPU processors  processors  CPU utilisation 

Many theories and guidelines dictate how burdened a processor should be at its most loaded state but which guideline is best for you? This article presents several ways to discern how much CPU throughput an embedded application is really consuming. You can use this information to verify the system software design versus a maximum processor load.

Selecting a processor is one of the most critical decisions you make when designing an embedded system. Your selection is based on the features required to satisfy the control functionality of the final product and the raw computing power needed to fulfil those system requirements. Computing power can be formally specified with benchmarks such as MIPS, FLOPS, Whetstones, Dhrystones, EEMBC marks, and locally contrived benchmarks. Many times, however, you won't know precisely how much raw throughput is needed when you select the processor. Instead you'll have only experience and experiential data to work with (from the microprocessor vendor or the systems engineer).

In any case, once the system development has progressed, it's in the team's best interest to examine the CPU utilisation so you can make changes if the system is likely to run out of capacity. If a system is undersized, several options are available: upgrade the processor (if possible), reduce available functionality, or optimise, optimise, optimise.

This article doesn't focus on any of those solutions but illustrates some tools and techniques I've used to track actual CPU utilisation. You can use these methods to determine how close to the "edge" a specific project is performing.

image name

Equation 1 through 4

Defining CPU utilisation
For our purposes, I define CPU utilisation, U, as the amount of time not in the idle task, as shown in Equation 1.

The idle task is the task with the absolute lowest priority in a multi-tasking system. This task is also sometimes called the background task or background loop, shown in Listing 1. This logic traditionally has a while(1) type of loop. In other words, an infinite loop spins the CPU waiting for an indication that critical work needs to be done.

Listing 1: Simple example of a background loop

int main( void )

   while(1) /* endless loop—spin in the background */();
   { ();
   nbsp; MonitorStack();
   nbsp; ... do other non-time critical logic here.

This depiction is actually an oversimplification, as some "real" work is often done in the background task. However, the logic coded for execution during the idle task must have no hard real-time requirements because there's no guarantee when this logic will complete. In fact, one technique you can use in an overloaded system is to move some of the logic with less strict timing requirements out of the hard real-time tasks and into the idle task.

Using a logic state analyser
Of the several ways to measure the time spent in the background task, some techniques don't require any additional code. Let's look at three techniques.

The first is an external technique and requires a logic state analyser (LSA). The LSA watches the address and data buses and captures data, which you can interpret. In this test, you should configure the LSA to trigger on an instruction fetch from a specific address and measure the time between each occurrence of an observation of this specific address.

The address to watch for could be any address within the while(1) loop from Listing 1. The task of identifying an appropriate address is tricky but not inordinately difficult. You can use the map file output by the linker to get close to a good address. Peruse the map file for the address of the main function, and then set up the LSA to look for the occurrence of any address within a limited range beyond the entry to main. This range is justified because, unless there's a large amount of logic between the entry to main and the start of the while(1) loop, the beginning of the loop should be easy to spot with a little iteration and some intelligent tweaking of the address range to inspect.

If your LSA can correlate the disassembled machine code back to C source, this step is even more straightforward because you only have to capture the addresses within the range known to hold the main function (again, see the map file output from the linker) and then watch for the while(1) instruction. If the while(1) loop is moved to its own function, perhaps something like Background(), then the location is much easier to find via the linker map file.

1 • 2 • 3 • 4 Next Page Last Page

Comment on "How to calculate CPU utilisation"
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top