This Blogpost will investigate the impact of different power management policies for SATA devices in Linux with regard to their power consumption as well as their performance impact. Because after all, everyone likes to get more battery life for free, right?

We will briefly discuss the test setup, then take a look at several measurement results for both power and performance to at the end take a look how to leverage the found results in practice.

Overall, we will find that for SSDs the power management policies for SATA devices can make a significant difference in power consumption while having a negligible impact on performance at the same time.

Background

On a modern linux machine, several modes for power management of a SATA drive are available. These are

  • max_performance: A disk is typically kept awake and running to get the best performance out of it. This is most indicative when thinking about spinning disks, as a spindown leads to inevitable significant latencies for the next access of the drive
  • min_power: This mode prefers power saving over maximum performance. For spinning disks this for example implies spindowns to save power
  • medium_power: A compromise between the aforementioned two.
  • med_power_with_dipm: This mode configures the drive like medium_power does, but with additional Device Initiated Power Management. It uses the same configuration the Intel IRST Windows driver uses to for drives.

Setup and Test Procedure

Setup

The measurement was performed on laptops and their internal SSDs. Due to availability to the author, the measurements were done with a Crucial M550 and a Crucial MX500, both 1TB in size. Measurements were taken with

  • Linux 5.3
  • no applications opened (except for the terminal with the benchmarking process)
  • screen turned off (only really relevant for power)
  • standard system daemons still running

Power consumption

The power consumption measurements were done using this code, to further reduce noise, wifi was disabled as well. After the link power management policy was set, the system was let idling for 10 minutes to reduce any influences from other policies or activities from before. Afterwards, power consumpiton was measured over 15 minutes via the /sys-API of the machine's battery controller. It was read every three seconds.

Three scenarios were tested for all available link power management policies:

  • idle: no induced activity
  • synchronous: activity right before reading the current power consumption
  • asynchronous: activity in the middle of two power measurements

The entire procedure was repeated for all combinations of available link power management policies and scenarios (so in total 12 times).

Performance

After setting the link power management policy and let the system idle to ensure measurements would not be influenced by past activity. Idle time was chosen to be 15 minutes (slightly longer as for power, an additional precaution as the performance measurements were significantly shorter time-wise that the power measurements). Performance was then measured using fio 3.16 with this preset adapted from here using this script. As benchmarking is hard, the performance measurements are not intended to be an absolute statement of the drive's performance, but rather intended as a ballpark measurement to get a feel for the performance impact of different link power management policies.

Results

Power consumption

MX500

Power consumption of the entire system with disabled screen and wifi during idle for Crucial MX500 for different power link management policies.

Power consumption of the entire system with disabled screen and wifi during idle for Crucial MX500 for different power link management policies.

Power consumption of the entire system with disabled screen and wifi right after activity for Crucial MX500 for different power link management policies. The steep rise for min_power is most likely explainable by an averaging artifact, as activity was just started with the power consumption measurement whereas the disk was idle before (and incidently also the entire idle-measurement was done before).

Power consumption of the entire system with disabled screen and wifi right after activity for Crucial MX500 for different power link management policies. The steep rise for min_power is most likely explainable by an averaging artifact, as activity was just started with the power consumption measurement whereas the disk was idle before (and incidently also the entire idle-measurement was done before).

Power consumption of the entire system with disabled screen and wifi with latent activity for Crucial MX500 for different power link management policies.

Power consumption of the entire system with disabled screen and wifi with latent activity for Crucial MX500 for different power link management policies.

M550

Power consumption of the entire system with disabled screen and wifi during idle for Crucial M550 for different power link management policies.

Power consumption of the entire system with disabled screen and wifi during idle for Crucial M550 for different power link management policies.

Power consumption of the entire system with disabled screen and wifi right after activity for Crucial M550 for different power link management policies.

Power consumption of the entire system with disabled screen and wifi right after activity for Crucial M550 for different power link management policies.

Power consumption of the entire system with disabled screen and wifi with latent activity for Crucial M550 for different power link management policies.

Power consumption of the entire system with disabled screen and wifi with latent activity for Crucial M550 for different power link management policies.

Performance

The measurements for the MX500 were very consistent when repeatedly measured. The measurements for the M550 were a bit flakey, so the fio-measurement on the M550 was performed three times and the performance characteristics shown are the respective medians over all three measurements for both throughput and latency.

Throughput

Read and write throughput for Crucial MX500 in MiB as measured with fio using the aforementioned preset.

Read and write throughput for Crucial MX500 in MiB as measured with fio using the aforementioned preset.

Read and write throughput for Crucial M550 in MiB as measured with fio using the aforementioned preset.

Read and write throughput for Crucial M550 in MiB as measured with fio using the aforementioned preset.

Latency

Latency information was gathered as part of the fio-measurements for the different link power management policies. The results (specifically lat in fio's output) are denoted as average +/- standard deviation in microseconds to, again, get a ballpark estimate.

MX500 seq-read rand-read seq-write rand-write
max_performance 55.51 +/- 15.63 137.86 +/- 44.33 55.45 +/- 203.61 60.66 +/- 201.69
medium_power 55.04 +/- 18.86 133.81 +/- 40.49 57.13 +/- 205.44 61.06 +/- 189.13
min_power 57.04 +/- 722.19 125.18 +/- 37.99 55.73 +/- 214.03 61.77 +/- 507.06
med_power_with_dipm 55.08 +/- 15.89 143.51 +/- 46.05 55.03 +/- 212.41 61.06 +/- 320.95
M550 seq-read rand-read seq-write rand-write
max_performance 187.91 +/- 40.64 207.68 +/- 26.32 73.61 +/- 571.03 93.28 +/- 898.61
medium_power 187.88 +/- 46.08 208.13 +/- 30.74 75.25 +/- 600.71 79.23 +/- 801.11
min_power 186.97 +/- 40.07 202.40 +/- 25.27 81.19 +/- 509.93 95.85 +/- 917.91
med_power_with_dipm 190.73 +/- 39.87 208.76 +/- 29.56 75.38 +/- 535.39 76.29 +/- 664.69

Conclusion

As the results clearly indicate, the power link management policy has a noticable impact on a computer's power consumption, up to a third of its total under light load when we exclude the screen. The newest mode med_power_with_dipm proves to be both among the lowest consuming ones for all modes for the tested SSD models and also very consistent in this, whereas other modes are either equal, systematically higher or highly dependent of the scenario at play (for example the min_power mode on the MX500).

The performance impact, both in latency and in throughput, was, however, somewhere between measurable and completely negligible, the highest impact could be seen in the throughput of the M550 where the data still implies med_power_with_dipm to be the preferred choice.

Beware that the results in this post are only applicable to SSDs. HDDs might have significantly different performance and power characteristics due to spin-down and spin-up times and other factors. Furthermore, the aforementioned results will likely apply for SSDs in general, but were obviously only tested on certain models. Different models, especially from differend vendors, could have different characteristics.

Practical usage

If you want to check which policy is in place, you can take a look at the content of the files /sys/class/scsi_host/host[0-9]/link_power_management_policy, which indicate the applied policy or simply use

cat /sys/class/scsi_host/host*/link_power_management_policy

to see the policies. After all, if you didn't configure anything, they should all be the same, so you'll see what's configured no matter which disk it is. To automatically set the desired policy, you can create a file /etc/udev/rules.d/disk-power.rules containing:

SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="med_power_with_dipm"

that will set med_power_with_dipm for all SATA disks that will show up. Alternatively, if you use tlp, you don't have to do anything, because (at least in the default configuration) tlp does already take care of setting this policy, at least for the primary SATA disk.

Appendix

Liteonit LCS-256, 256GB

One additional dataset was donated from an additional SSD, specifically a Liteonit LCS-256, sized at 256GB. Below you find the power measurements for this disk, the measurement procedure is roughly equal to the one outlined for Crucial's MX500 and M550 above. We see that, while the exact numbers vary, the power profiles behave very similar, specifically to the ones of the MX500, and our conclusions apply for this disk as well.

Power consumption during idle for Liteonit LCS-256 for different power link management policies.

Power consumption during idle for Liteonit LCS-256 for different power link management policies.

Power consumption right after activity for Liteonit LCS-256 for different power link management policies.

Power consumption right after activity for Liteonit LCS-256 for different power link management policies.

Power consumption with latent activity for Liteonit LCS-256 for different power link management policies.

Power consumption with latent activity for Liteonit LCS-256 for different power link management policies.

If someone has a disk or SSD manufacturer not covered so far, feel invited to still send data to broaden the survey started here.