Power savings using different tunables on Fedora 12
On this page we've collected test results for the various methods that are currently available on Fedora to save power on a running system.
For each method that we tested we separated the information into the following subsections:
- What does it do and how does it work
- How can i activate/deactivate it
- Measurement results
- Comments/Discussion
Test hardware
As a test platform we were using the following hardware:
Dell Latitude D620:
- CPU Intel Core Solo T2500 2.0 Ghz
- GPU Nvidia GeForce Go 7300
- Chipset Intel Mobile 945
- HDD Seagate Momentus 7200 100GB
- Network Broadcom NetXtreme BCM5752 Gigabit
- 15" 1440x900 LCD
- Memory 2GB
The reason for using a laptop for now was that we were still missing wattmeter with high enough precision to measure the oftentimes little improvements we've seen.
How we tested
To avoid errors in the results we've decided to measure all results in single user mode with networking enabled afterwards (service network start). This proved to be the most realiable form for measurements. It will also typically yield the highest possible saving for each of the shown methods, so it's a good reference for what you can achieve in the best possible circumstances.
In order to gather the data we booted the system fresh into single user mode each time with a fully charged battery, started the network via service network start, activated the tunable we wanted to measure and ran the following command:
for i in seq 6; do powertop -d -t 30; done
and wrote down the watt usage of each output. This way we avoided having side effects from deactivating previous tunings and used the same start for powersupply from the battery for each test.
The Tests
Untuned system
What and how
Here we simply started the system and measured it's idle non-tuned state as a baseline for comparison.
Activate/decativate
Doesn't apply for this test, obviously. :)
Measurement results
| 0:00 | 0:30 | 1:00 | 1:30 | 2:00 | 2:30 | Average |
|---|---|---|---|---|---|---|
| 28.3 | 28.4 | 28.3 | 28.3 | 29.4 | 29.2 | 28.65 |
Comments/Discussion
Not much to say here. It's a rather old laptop (nearly 4 years now) and therefore is using quite a bit of power in a completely untuned state.
hdparm
What and how
This time we've used hdparm to allow the hard disk to spin down and activated the highest power saving mode available.
Activate/decativate
Activate: hdparm -S 1 -B 1 /dev/sda
Deactivate: hdparm -S 0 -B 255 /dev/sda
Measurement results
| 0:00 | 0:30 | 1:00 | 1:30 | 2:00 | 2:30 | Average |
|---|---|---|---|---|---|---|
| 26.4 | 26.5 | 26.5 | 26.5 | 26.5 | 26.3 | 26.45 |
Comments/Discussion
As soon as the harddisk can spin down we're saving around 2.2 watts on this laptop. This is roughly what we've expected and typical for an older 2.5" laptop harddisk. Newer harddisks in laptops use quite a bit less power, and going towards SSD that goes down to virtually 0.0 immediately when they aren't used. For desktop system the difference between active (read/write), idle and standby/sleep are 8.0 vs. 6.0 vs 1.0 watt. Some of the newer green desktop drives go down to 4-5 watt in idle mode and 6 watt in active mode, so savings can be a bit higher on desktop machines.
There are 2 rather noticable negative effects about putting drives in standby while sitting in front of the machine though:
- If the standby time is too short the drive will spin down and up rather often which will reduce the lifetime of it considerably. With modern drives you can do around 50000 startp/stop cycles. If your drive spins up and down just once an hour this results in a lifetime expectancy of 5 1/2 years. If it happens every 6 minutes, this goes down to just 6 months.
- With older drives the spin up from standby mode can take several seconds, even longer for desktop or server harddisk. This can be rather annoying if it happens every time you want to access the disk.
So instead of using a very short standby timeout as we did for the tests a much higher one is recommended. Using
hdparm -S 240 -B 1 /dev/sda
will put the harddisk in standby after 20 minutes of inactivity. This is a much safer setting and even in the absolute worst case you'd still have a life expectancy of 2 years on modern harddisks.
Also combining this with enabling laptop_mode and increasing buffer flush times will result in a lot less disk accesses from the Linux kernel. You can activate that with the following commands:
echo 5 > /proc/sys/vm/laptop_mode
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
In our tests those didn't make a difference as in single user mode the kernel typically doesn't have anything to write which makes the above commands unecessary.
ethtool
What and how
This time we've used ethtool to reduce the speed of the network interface down to 100mbit.
Activate/decativate
Activate: ethtool -s eth0 advertise 0x000F
Deactivate: ethtool -s eth0 advertise 0x003F
Measurement results
| 0:00 | 0:30 | 1:00 | 1:30 | 2:00 | 2:30 | Average |
|---|---|---|---|---|---|---|
| 27.0 | 28.1 | 28.1 | 28.1 | 26.9 | 26.8 | 27.50 |
Comments/Discussion
Using a lower autonegotiate speed for our card reduced the the our power usage by 1.1 watt. It is important to note that we didn't set the speed, as is recommended sometimes at other places. Forcing the card into a specific speed basically disables autonegotiation and oftentimes results in broken connections to the hub or switch on the other side which either still expect to run at 1gbit or fall back to a halfduplex mode. Obviously that is rather bad and reduces the performance quite drastically. Using a lower autonegotiation speed avoids this typically as your card basically acts as if it would be a 100mbit card instead.
We've tried reducing the speed even further down to 10mbit, but the power saving was basically not noticable anymore (somewhere around 0.1-0.2 watt less, but that could easily be in the margin of error as well), so 100mbit will is what you should be using to save a bit of power.
Of course the only noticable negative side effect is that your transfer speed will go down to a maximum of 10 MB/sec and your latency will increase minimally in your LAN. In most of the cases this shouldn't matter though, except if you're transfering lots of data to/from your machine over the net lots of times. And if you do then you can always quickly disable this tuning while you do the large transfer.
ALPM
What and how
ALPM or Active Link Power Management allows kernel to reduce power or shut down completely inactive SATA ports on PCI express lanes. Typically SATA are powered even if no cable is plugged in, and powering those down saves approx. 1 - 1.5watt per port. This only works for PCI express and for non-hotpluggable SATA ports at the moment.
Activate/decativate
Activate: for i in /sys/class/scsi_host/host*/link_power_management_policy; do echo min_power > $i; done
Deactivate: for i in /sys/class/scsi_host/host*/link_power_management_policy; do echo max_performance > $i; done
Measurement results
| 0:00 | 0:30 | 1:00 | 1:30 | 2:00 | 2:30 | Average |
|---|---|---|---|---|---|---|
| 29.3 | 29.5 | 29.3 | 28.0 | 28.2 | 28.3 | 28.77 |
Comments/Discussion
Unfortunately the laptop obviously doesn't have any SATA controllers with ALPM support, so no savings could be observed during our tests.
In general though what we've seen with manual long term measurements on a modern desktop system the effect is really approximately 1 watt per inactive port.
With min_power ports can be virtually shut down completely. This can cause a small latency when the port is used again, roughly up to 40ms.
Some problems with raids and min_power have been reported in the past, but we haven't noticed those in the tests we've done on the desktop system.
If you want to be careful you can use
for i in /sys/class/scsi_host/host*/link_power_management_policy; do echo min_power > $i; done
which won't completely power down the SATA port. This is already the default in Fedora 12 though, so normally you won't have to do this.
USB autosuspend
What and how
This time we've enabled USB autosuspend for all devices that support it.
Activate/decativate
Activate: for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done
Deactivate: for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 0 > $i; done
Measurement results
| 0:00 | 0:30 | 1:00 | 1:30 | 2:00 | 2:30 | Average |
|---|---|---|---|---|---|---|
| 28.3 | 28.2 | 28.1 | 28.1 | 28.4 | 28.2 | 28.22 |
Comments/Discussion
USB autosuspend had a smaller effect than the others we did, only around 0.4 watt. The reason for this is probably that there wasn't a lot of USB hardware attached to the laptop to begin with. Using USB devices that use more power when they are active and that properly support autosuspend would have shown more obvious results.
Unfortunately there are a few problems with USB autosuspend, especially with external devices. Here a short list of things that can go wrong with USB autosuspend:
- Some devices go to sleep but never wake up again even when accessed. Need to completely replug it then in order to work again.
- Some devices go to sleep too quickly. We've seen some external USB harddisk storage going to sleep after 5 seconds of inactivity. As there is no way of specifiying a timeout this is rather bad and you can't use USB autosuspend on such devices properly.
- Some devices claim to support USB autosuspend but have buggy implementations, leaving the device in an unusable state which requires replugging.
Tuned
What and how
This time we've used tuned, the new tuning daemon we introduced in Fedora 11. Tuned basically combines the hdparm and ethtool tuning on a dynamic basis where it monitors the use of the harddisk and the network devices and tunes them up or down depending on activity. For Fedora 12 we've also added PM-QOS support which increases the latency if the load is rather small on the system.
Activate/decativate
Activate: service tuned start
Deactivate: service tuned stop
Measurement results
| 0:00 | 0:30 | 1:00 | 1:30 | 2:00 | 2:30 | Average |
|---|---|---|---|---|---|---|
| 26.0 | 25.9 | 25.2 | 25.2 | 25.3 | 25.2 | 25.47 |
Comments/Discussion
As expected, the overall saving is around 3.2 watt, which is basically hdparm and ethtool savings added together.
For idle systems PM-QOS doesn't seem to have any effect whatsoever, which isn't really surprising as the system hardly wakes up at all anyway.
As pointed in the end section this is something we'd like to investigate further.
Overall conclusion and discussion
We've shown various power saving tunables that can be activated in userland. Some of them didn't show any results, but that was basically always due to lack of support in the hardware (ALPM mainly and USB autosuspend to a smaller degree). The reason why most of those tunables aren't enabled by default is that they either impact usability of the system by reducing performance noticably or that they impose a greater danger of data loss in case of a system crash or can reduce the lifetime of components.
What we'd like to get is measurements for ALPM and USB autosuspend on supported hardware. As soon as we get those we'll post a new page with measurements for a typical modern desktop system.
Another interesting topic would be to investigate if PM-QOS offers any clear and measurable benefits on servers with low to medium load.