Desktop Power Consumption
General improvement of power consumption
- Steve Langasek
- Martin Pitt
- Martin Pitt
- Series goal:
- Accepted for precise
- Milestone target:
- Started by
- Martin Pitt on 2012-03-28
- Completed by
- Martin Pitt on 2012-03-28
[vorlon] Repackage the old powertop: DONE
Write "fatrace" tool to log disk accesses (https:/
Package fatrace: DONE
Write tool for users to run that collects wakeups (from powertop) and disk accesses (from fatrace) over a minute and generate a report: DONE
add anonymized strace snippets to above tool for the biggest offenders: POSTPONED
[colin-king] Explain process for identifying power issues and how to report them: (see https:/
[colin-king] Need to better understand what the /proc/acpi numbers mean; compare with known good #'s (see http://
Investigate blktrace for reporting issues with excessive disk wakeups: DONE
[colin-king] investigate power difference between black or white screen (even for DPMS off): (http://
[colin-king] investigate impact of reducing psmouse frequency from 100 to e. g. 40 (see http://
[ev] Work with pitti to submit power data to the metrics database: POSTPONED
UDS meeting notes (edited)
- current desktop does not seem to produce inordinate number of wakeups any more
- Colin King wants to set up accurate power measurement for precise
- stop X.org for measuring the impact of e. g. PCI device PM, to avoid the noise of mouse events/syndaemon
- reduce psmouse frequency from 100 to 40 seems to make a big difference. Probably would prefer finding a compromise value rather than dynamically changing settings like these.
- Lots of issues are HW-specific things. Wireless cards, proprietary drivers, etc. These need bug reports and are not covered here.
- There is a ubuntu-power project which you can assign or subscribe bugs to that have power impact, and that should be priority for power improvement.
- Measurements should take the currently consumed Watts, not remaining battery life, as the latter depends on the battery type/age/estimates
- Unclear how accurate /proc/acpi data is.
- in general, powertop is considered the best tool for measuring this, especially the older version
- current PowerTop is useless; need to get the one from natty. The new one is completely missing the implementation of the wakeups/s detection through /proc/timer_stats, which 1.13 did
- perf might be a useful tool alongside strace, to get a handle on kernel power issues. Need someone to investigate this and wire it up. Other tools (systemtap, et al) could be considered as alternatives.
- Disk wakeup on non-ssds. Desktop keeps waking up disk so it can't just park the heads. Need to get tools in place to be able to keep measurements on this. There are lots of voodoo suggestions for optimization (e.g. tune/shutdown syslog) which would be better to have actual measurements on, so we can determine why it's doing what it's doing.
- USB suspend is not safe, so we cannot enable it by default.
- Unknown whether enabling PCI PM on all devices is safe
ACPI battery status reliability from Colin King
Although this is based on the sample of just one machine, we can see
that ACPI battery data when averaged over several minutes on a system
that does not have rapidly changing power consumption is relatively
accurate, within a few percent of the real power consumption.
* Short term measurements should not be trusted, there is way too much
variability in battery data.
* Measurements should be run for several minutes on a system running in
a steady state. Don't trust results that haven't run for at least 5 minute
== PowerTop Notes ==
Powertop seems to gather data and only really trust the data after ~400
seconds of samples and then only it displays ACPI data after 5 minutes
of running. If we run powertop to measure data, I suggest we ensure it
runs for at least 10 minutes, 5 to gather the initial data and 5 to
gather the long term average data. However, I'm working on the
powerstat tool which will gather data and calculate averages + standard
deviation results to make this a little easier.
blktrace investigation from Martin Pitt
blktrace is a very low-level tool which is hard to use, only gives you sector numbers (for which there is no known way to map them back to blocks, inodes, and/or path names), and also is skewed by caching. It turned out that fanotify() is a much easier, efficient, and useful approach to monitoring the disk for events. So the tool will be written using fanotify for disk I/O and wakeups/tweaks using powertop-1.13 -d. I also split off the work item about adding straces, as the tool is useful even without that, and it can potentially be reassigned or postponed.
power-usage-report script now in Precise, see http://