Editing N900 software power management
Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
+ | This is a work in progress. | ||
+ | It is not yet ready for public consumption. | ||
+ | Please don't link it into wiki yet. | ||
+ | |||
+ | =Overview= | ||
This page may be useful to application developers, as well as those interested in reducing power usage of software by configuring it correctly. | This page may be useful to application developers, as well as those interested in reducing power usage of software by configuring it correctly. | ||
- | |||
- | |||
==Why software uses power== | ==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. | 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 | + | For example, it might be nice to always keep the backlight on, from a user-experience point of view, but this will lead to a battery life of several hours at best, so the compromise of blanking the screen when inactive and on battery is usually made. |
- | + | ==Direct== | |
+ | Direct power use is quite simple. | ||
+ | The intended function of the application uses power. | ||
+ | For example, 'flashlight'. | ||
- | + | This application turns on the [[N900 Hardware Flash Torch|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 | + | 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. | |
- | 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. | + | ==Indirect== |
+ | 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. | 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. | ||
- | == | + | ==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. | |
- | == | + | ==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. | |
+ | =Details of each case, with examples.= | ||
+ | ==Direct== | ||
+ | ==Indirect== | ||
+ | ==Pathological== | ||
+ | ===Avoidable=== | ||
* Not properly becoming idle when the screen is locked. | * 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). | * 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). | ||
Line 44: | Line 61: | ||
* 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) | * 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) | ||
- | + | ===By Design=== | |
+ | ===Unavoidable=== | ||
- | ==== | + | =Tools= |
+ | ==Powertop== | ||
+ | ==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. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
Please note the warning, experimenting with the tools in this package may cause hardware damage. Know what the [[N900 Hardware Bus I2C|I2C]] bus and device you are accessing is, before making any changes to the below. | Please note the warning, experimenting with the tools in this package may cause hardware damage. Know what the [[N900 Hardware Bus I2C|I2C]] bus and device you are accessing is, before making any changes to the below. | ||
+ | #!/bin/sh | ||
+ | echo 0 >/proc/timer_stats | ||
+ | while true | ||
+ | do | ||
+ | echo 1 >/proc/timer_stats | ||
+ | sleep 5 | ||
+ | echo 0 >/proc/timer_stats | ||
+ | echo `date` $((`i2cget -y 2 0x55 0x14 w` * 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. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | The output of the above is quite simple. The below is the result of sshing into the | + | |
./powermeter | ./powermeter | ||
Line 123: | Line 93: | ||
... | ... | ||
- | This shows that immediately after starting, the script measured over the first | + | This shows that immediately after starting, the script measured over the first 5s a power consumption of 25mA. This will discharge in one hour the battery by 25milliamp-hours. It has a total capacity of around 1200mAh - so will last about 1200mAh/25mA = 75h (roughly. |
- | Wifi however uses a significant amount of power. By comparison, this is the result when redirecting the output to a file. | + | 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:34:56 BST 2010 66mA 30 total events, 5.983 events/sec | ||
Line 132: | Line 104: | ||
... | ... | ||
- | Again, there is an initial burst of current consumption, but this time it levels out to | + | Again, there is an initial burst of current consumption, but this time it levels out to 6mA - or around 200 hours. |
- | + | What does the rest of the line mean? It's simply a very abbreviated output as provided by powertop. | |
- | + | See that section. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
+ | ==Top== | ||
===Htop=== | ===Htop=== | ||
- | + | ===Dbus-monitor=== | |
- | + | ===mdbus2=== | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + |
Learn more about Contributing to the wiki.