• Intro
• Downloads
• Community
• Development
• News
• TALK

N900 software power management

Latest revision as of 18:03, 4 September 2017

This page may be useful to application developers, as well as those interested in reducing power usage of software by configuring it correctly.

Also refer to http://www.lesswatts.org/projects/applications-power-management/

[edit] Why software uses power

Software should use power to do what the user wants in the most battery efficient way, without letting the battery efficiency get in the way unless it's unavoidable.

For example, it might be nice to always keep the backlight on but to get more than a few hours battery life the compromise of blanking the screen when inactive and on battery is usually made.

[edit] Direct Use

Direct power use is quite simple. The intended function of the application uses power. For example, 'flashlight'. This application turns on the LED Flash so the user can see.

Once it is active, it needs no CPU, and the screen can be blanked. Almost all of the battery usage in this mode is to cause the desired effect. 'Flashlight' as an application could be viewed as 95% efficient - only 5% or so of the battery is used for stuff other than keeping the flash lit.

[edit] Indirect Use

Indirect is when there is no direct hardware way to perform an action, and some part of the system has to be made to do this without the user explicitly turning it on. For example, a task-list application might want to alert the user if they get within a certain distance of a task, so they could consider doing it. So, the application needs some means to get a notion of location. For example, it could run the GPS, or scan wifi networks in range.

The user doesn't know or care about how the application does it, but how it is done may have a significant effect on battery life.

[edit] Pathological

The application chooses - or the system software only permits - an inefficient way to perform a task.

For example, an alarm application that after it has been told to beep after 12 hours, turns on the audio system immediately to make that beep, then checks every second to see if the 12 hours is up yet.

[edit] Details of each case, with examples

[edit] Direct

[edit] Indirect

[edit] Pathological

[edit] Avoidable

• Not properly becoming idle when the screen is locked.
• Leaving GPS on when screen is locked, when it does not aid the application. (for example, if the application gets a GPS fix, displays location related data, and does not turn off the GPS, even when the screen is locked).
• Keeping audio active when idle. Pulseaudio can use a large amount of power in some cases, playing 'silence'.
• Improper use of timers. If you need to do something every second to update the display, don't do it when the screen is locked, or your window is hidden.
  • If you need to update internal state, and you normally do this every time you update the window, consider carefully how infrequently you can do this when the user is not looking at the display.
• Listening to events that are irrelevant. When you got a mainloop with a central wait like e.g pause() (2), then you should not create a situation where irrelevant events cause signals sent to the waiting process and cause "active discarding" of the signal. Generally whenever there's a test in a signal handler subroutine that discards certain classes of signalled events, you should check if there's no way to disable the signals from being sent to your process at all. (Example: a widget that doesn't react to any touchscreen events is maybe better off not to receive any X events at all. Especially applicable if this property not to care about touchscreen events is just temporary - don't make the process use CPU time just to decide it's been an event that doesn't matter)

[edit] By Design

[edit] Unavoidable

[edit] User Training

User training is very important, in some ways more important than the rest of this guide. In some cases, there is no way for the user to avoid battery use. They need to see - they turn on 'flashlight'. In others, minor changes to their behaviour, that might even make their experience better, may greatly change battery life.

For example, when listening to audio, if the user knows that instead of streaming programs from their local radio station over 3G, both FM radio or downloading a podcast over wifi would use a tiny fraction of the power, they can make that choice.

[edit] Measuring power usage

[edit] Tools

[edit] Power Measurement

[edit] What is power?

The battery stores an amount of energy enough to lift the phone around 10 km in the air. Power is the rate of use of that energy. The battery is charged or discharged by electrical current flowing into or out of it.

Current*Battery voltage = power.

The below tools directly measure electrical current usage by the phone. They should be run with the device unplugged from USB. Battery capacity is measured in Amp-Hours. The BL-5J in the N900 has a capacity of 1.4 Ah. It can provide 1 A for a little over an hour, but it's very hard to get it to use that much. If the current drops, the time rises.

For example, in standby with wifi and phone enabled but idle, the current usage is around .006 A, leading to a standby life of around 10 days. (1.4 Ah/.006 A = 220 h = 10 days. 0.006 A is a cumbersome figure, so the unit 'Milliamp' - mA - 1/1000th of an amp is used. 6 mA when idle is great, but it is easy if everything does not go right to use lots more than this when idle. For example, if the CPU is constantly active, it will use over 100 mA - draining the battery in around 12 hours.

[edit] Debugging

If the wireless router, and the N900 are setup correctly, then wifi is a very useful aid to debugging. The ssh package] installable from extras allows you to login to the mobile, and run software to debug power usage, with very little additional consumption.

The package screen allows you to run command line programs that would normally output lots to screen, without causing any wifi traffic (or consuming any power) when you are not looking at them.

[edit] Powerscript

The below is a simple script to read the bq27200 battery meter, and output instantanous current, as well as wakeups/second. It outputs once per 5 seconds a summary of the activity in the preceding period. Install i2c-tools from extras-devel, or the power-kernel from extras.

Please note the warning, experimenting with the tools in this package may cause hardware damage. Know what the I2C bus and device you are accessing is, before making any changes to the below.

#!/bin/sh
modprobe -q bq27x00_battery
 
if [[ -e /sys/class/power_supply/bq27200-0/current_now ]]
then
  current_read='cat /sys/class/power_supply/bq27200-0/current_now'
  echo Using kernel battery driver to read current.
else
  if  command -v i2cget >/dev/null
  then
    current_read='i2cget -y 2 0x55 0x14 w'
    echo "Using I2C to read charge meter directly"
  else
    echo "Cannot find a way to read the charge meter."
    echo "Either i2ctools from extras-devel must be installed, or the power kernel with the bq27x00_battery module which normally accompanies it."
    echo "Exiting."
    exit
  fi
fi
#                                      Reset timer stats.
echo 0 >/proc/timer_stats
while true        #                    Loop while printing stats
do
  echo 1 >/proc/timer_stats   #          Start gathering stats
  sleep 5                     #          Sleep 5s
  echo 0 >/proc/timer_stats   #          Finish stats.
#                                        Print output, assuming sense resistor is 22 milliohms.
  echo `date` $((`$current_read` * 3570 / 22 / 1000))mA `tail -1 /proc/timer_stats`
done

The output of the above is quite simple. The below is the result of sshing into the N900, and running the script.

./powermeter 
Sat Aug 7 21:34:29 BST 2010 25mA 27 total events, 5.367 events/sec
Sat Aug 7 21:34:34 BST 2010 14mA 29 total events, 5.780 events/sec
Sat Aug 7 21:34:39 BST 2010 15mA 38 total events, 7.557 events/sec
Sat Aug 7 21:34:44 BST 2010 16mA 25 total events, 4.987 events/sec
...

This shows that immediately after starting, the script measured over the first 5 s (actually for the 5s window that ended before script started) a power consumption of 25 mA. This will discharge in one hour the battery by 25 milliamp-hours. It has a total capacity of around 1200 mAh - so will last about 1200 mAh/25 mA = 75 hours (roughly).

Wifi however uses a significant amount of power. By comparison, this is the result when redirecting the output to a file.

Sat Aug 7 21:34:56 BST 2010 66mA 30 total events, 5.983 events/sec
Sat Aug 7 21:35:01 BST 2010 6mA 13 total events, 2.592 events/sec
Sat Aug 7 21:35:06 BST 2010 6mA 27 total events, 5.382 events/sec
...

Again, there is an initial burst of current consumption, but this time it levels out to 6 mA - or around 200 hours. What does the rest of the line mean? It's simply a very abbreviated output as provided by powertop.

[edit] Analysis tools

If you've found that the system is using too much power when an application is running or idle, the tools below help to diagnose why.

[edit] Powertop

Obsolete by http://maemo.org/packages/view/zzztop/

The output of powertop, when run as root, is shown below, with some comments. Much of the output is probably not directly useful for you.

 Powertop 1.13.3
 status: Unknown job: pmtrackerdaemon
 Sleeping for 11 seconds before sampling
 Collecting data for 30 seconds
 Sample interval was 00m 30s 18921us

Initial block, with normal error.

C#      | Ratio  | Avg/dura | Frequency | Ratio
--------+--------+----------+-----------+--------+
     C0 |   0.3% |          |   600 MHz |   0.0% |
     C1 |   0.0% |    0.2ms |   550 MHz |   0.0% |
     C2 |   0.4% |    4.7ms |   500 MHz |   0.0% |
     C3 |   4.5% |  134.6ms |   250 MHz | 100.0% |
     C4 |  94.8% | 2032.8ms | 

During this period, the CPU was active 0.3% of the time (in the C0 state). Of this 0.3% of the time, 100% of it - so 0.3% total - was spent at 250 MHz. It spent very little time in the C1 through C3 states, which are increasing depths of sleep, and the majority of the time (94% of the 30s - or about 28s) in the C4 state which is the deepest state that uses least power. The Average duration is how long it typically spent in each state. In this case the C4 duration indicates that it's spending typically over 2 seconds asleep at a time - this is the most efficient power state.

If you are testing an application, and when idle you get numbers close to these, then battery life is unlikely to be affected by the application. (though there may be ways to make it use power when idle that you've missed).

IRQ#    | Activity   | Type           | Name
--------+------------+----------------+---------------------------
     56 |        129 |           INTC | i2c_omap
     12 |         59 |           INTC | DMA
     37 |         48 |           INTC | gp
     11 |         39 |           INTC | prcm
     57 |         28 |           INTC | i2c_omap
    202 |          3 |           GPIO | wl1251

This shows how many interrupts occurred in the period. Most of these are not influenced directly by user software. The exception may be wl1251 - this is the wireless card.

PID#    | Activity   | Name           | Function Entry (Expire)
--------+------------+----------------+---------------------------
      0 |         20 |  <kernel core> | tick_nohz_restart_sched_tick (tick_sched_timer)
     37 |         14D|            awk | cpufreq_governor_dbs (delayed_work_timer_fn)
      0 |         12 |  <kernel core> | hrtimer_start (tick_sched_timer)
    753 |          7 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)
      0 |          6 |  <kernel core> | queue_delayed_work (delayed_work_timer_fn)
    470 |          3 |         wl12xx | schedule_timeout (process_timeout)
(30 lines deleted)

This is one important bit. It lists process ID (0 is internal kernel), how many times in the 30 s it was woken, and what the name of the system waking it up was, as well as what timer ran out.

The 'awk' here is a a kernel bug, it should read '<kernel core>' as this is really the kernel checking if it needs to change CPU speeds.

This shows the only user process is bme_RX-51 - this is BME - the battery managment entity - which wakes every few seconds to monitor the battery.

Power domain activity breakdown
Domain  | % of time spent in states
--------+---------+---------+---------+---------+----------
usbhost |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)
    sgx |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)
    per |OFF:  99%|RET:   0%|INA:   0%| ON:   0%| now:(ON)
    dss |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)
    cam |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)
   core |OFF:  94%|RET:   4%|INA:   0%| ON:   0%| now:(ON)
   neon |OFF:  94%|RET:   4%|INA:   0%| ON:   0%| now:(ON)
    mpu |OFF:  94%|RET:   4%|INA:   0%| ON:   0%| now:(ON)
   iva2 |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

This shows how often various parts of the chip were switched on/off - this will normally not be useful.

Clock activity breakdown at end of period
Domain  | Active clocks
--------+---------------+---------------+------------------
   core |          SDRC | HSOTGUSB_IDLE |      OMAPCTRL 
        |     MAILBOXES |
   wkup |          GPT1 |       32KSYNC |         GPIO1 
        |          WDT1 |
  ckgen |          CORE |          PERI |           96M 
        |           48M |           12M |           54M 
        |      EMU_CORE |
    per |         GPIO2 |         GPIO3 |         GPIO4 
        |         GPIO5 |         GPIO6 |

This is also not usually useful.

Total wakeups   394,  13.1/s | IRQ  306,  10.2/s | Timers   88,   2.9/s
HW wakeups       39,   1.3/s |     Real gp_timers expired   48,   1.6/s

[edit] Strace

The utility strace can be downloaded from the sdk/tools repository using

apt-get install strace

strace shows what system calls the process is making. The manpage has more information.

The most basic usage is:

strace ls

Though you can also attach to a running process - say process 833.

strace -p 833

[edit] Htop

Htop is a much more flexible tool than the installed version of top.

It is in extras, and can be installed simply from the command line by issuing the command

apt-get install htop

Full documentation can be found at the htop project pages on sourceforge (in case you wonder: the F(n)-keys can get typed on N900 as ESC-<n>, so ESC + "1" for F1)