MeeGo 1.2 Harmattan Developer Documentation Develop for the Nokia N9

Using PowerTOP

PowerTOP is a tool you can use to track wake-ups and system states. In short, the program records a number of statistics related to energy consumption for a period and then displays a summary of the results. The results can be used to see how many wake-ups your application causes, or how some sensor used by your application affects the system.

Installing PowerTOP on the Harmattan device

Install PowerTOP through the developer mode applet.

Prerequisite: Developer mode must be enabled.

  1. Select Settings > Security > Developer mode.
  2. Install the Power analysis bundle package by clicking Install.
  3. You get a notification screen that lists all the applications to be installed in the bundle package. To install, click OK.
  4. A dependency notice appears. Click Accept.

For more information on developer mode and installable tools, see Activating developer mode.

Using the tool

You can use PowerTOP to measure system behaviour, such as C states, frequencies, interrupts, and wake-ups.

Invoking PowerTOP

When measuring the system behaviour, you do not want the measurement itself to affect the results. Pay attention to the way you start the application and how you process the messages from the program. For example, if you run the program in a terminal window without redirecting the output, the message "Collecting data for x seconds" causes extra activity when your terminal window is updated. Redirecting to a file residing in a USB mass media or to a flash memory device causes peripheral activity and interruptions as well, so your best approach is to redirect the output to a RAM disk and copy it from there after the run.

The device performs some background maintenance tasks for a considerable period of time after booting up. It is recommended to wait at least 15 minutes before any measuring activities after booting the device.

If your application runs on the background and you want to measure the impact when the device is idle, add a delay to the PowerTOP invocation, so that the device has time to blank the display and to go into sleep mode. You can accomplish this with the -s switch, which takes an argument indicating the number of seconds to sleep before performing the measurement.

You can control the length of the measurement period with the -t flag, which takes an argument specifying the length of the measurement period in seconds.


powertop -s 60 -t 60
Powertop 1.13.67
Sleeping 60 seconds before sampling
Collecting data for 60 seconds
Sample interval was 01m 00s 33051us

Reading the output

First, measure the system without your application to get a baseline result. Try to keep all other things equal to the measurement you are performing with your application. For example, if you are measuring you application's behaviour when the display is not blanked, do not allow the display to go blank during the baseline measurement either. Then measure your application and compare the results to get the total effect your application (and user activity, if you measure interactive use) has on the system.

The meaning of individual output sections is explained in the sections below.


C-states are different sleep states, where C0 is active state and the other states are different sleep states. The states with the highest numbers save the most energy. The longer the system can stay in the deepest possible sleep state, the better. Note that both individual visits and total time spent in the lowest power states must be as long as possible. Short visits in the lowest power states are not useful.

     Available C-States     |
C#      | Ratio  | Avg/dura |
     C0 |   0.7% |          |
     C1 |   1.2% |    0.4ms |
     C2 |   0.0% |          |
     C3 |   0.0% |          |
     C4 |   0.0% |          |
     C5 |   0.0% |          |
     C6 |   0.0% |          |
     C7 |  98.1% |  234.6ms |
     C8 |   0.0% |          |


The device may scale the CPU frequency based on demand. PowerTOP can record the time each frequency was being used during the measurement period:

|   Available Freqs  |
| Frequency | Ratio  |
|  1000 MHz |   0.0% |
|   800 MHz |   0.0% |
|   600 MHz |   0.0% |
|   300 MHz | 100.0% |


PowerTOP records the number of times the different hardware interrupts occur during the measurement period. As a general rule, you do not need to worry about these. However, if you use a sensor, you can use this information to see if requesting lower service level from the sensor causes less interrupts and therefore causes fewer system wake-ups. These results depend, of course, on the components that are used, so the result can vary depending on device model.

IRQ#    | Activity   | Type           | Name
     57 |       3299 |           INTC | i2c_omap
     37 |        290 |           INTC | gp
     11 |        252 |           INTC | prcm
     74 |        251 |           INTC | serial
    243 |        183 |           GPIO | apds990x
     56 |         94 |           INTC | i2c_omap
      7 |          4 |           INTC | TWL4030-PIH
    371 |          4 |        twl4030 | twl4030_madc

Software wake-ups (timers)

This section is possibly the most important section to check, especially if your program runs in the background while the device is otherwise idle. This section lists every wake-up caused by a software timer and the kernel function related to the wake-up. You can use this section to track the number of wake-ups your application causes, when you are trying to reduce them. Note that sometimes accessing a sensor or other peripheral device may cause your application to cause wake-ups even if you do not have timers in your own code. For example, bme_RX71 below has 7 wake-ups related to i2c. As long as the peripheral is used, you can ignore wake-ups caused by the use.

PID#    | Activity   | Name           | Function Entry (Expire)
      0 |        219 |  <kernel core> | hrtimer_start_range_ns (tick_sched_timer)
    254 |        204 |irq/243-apds990 | omap_i2c_xfer (omap_i2c_clock_timer_fn)
     18 |        183D|    kondemand/0 | do_dbs_timer (delayed_work_timer_fn)
    363 |         60 |first-boot-prot | __enqueue_rt_entity (sched_rt_period_timer)
     13 |         60 |irq/7-TWL4030-P | __enqueue_rt_entity (sched_rt_period_timer)
    495 |          7 |      bme_RX-71 | omap_i2c_xfer (omap_i2c_clock_timer_fn)
    393 |          5 |           dsme | hrtimer_start_range_ns (hrtimer_wakeup)
      4 |          4D|       events/0 | neigh_periodic_work (delayed_work_timer_fn)
    416 |          2 |        syslogd | hrtimer_start (it_real_fn)
   1058 |          2 |mapplicationext | hrtimer_start_range_ns (hrtimer_wakeup)
    442 |          1 |    dsme-server | hrtimer_start_range_ns (hrtimer_wakeup)
      4 |          1D|       events/0 | worker_thread (delayed_work_timer_fn)
   2541 |          1 |       powertop | hrtimer_start_range_ns (hrtimer_wakeup)

Power domain and clock activities, and summaries

These sections display the net effect caused by the peripheral device, network and mass storage accesses. Since your application is not able to directly improve these results, you can concentrate on the other sections described above.