Power Management

Idle power management for SSDs can be surprisingly complicated, especially for NVMe drives. But it is also vitally important for any battery-powered system. Real-world client storage workloads leave SSDs idle most of the time, so idle behavior is a big factor in how battery-friendly a drive is. Power draw when idle isn't the only thing that matters; how quickly a drive can enter or wake up from a low-power state can have a big impact on how effective its power management is.

For SATA SSDs, the host system doesn't have a lot of say in how the drive manages power. Using the SATA Aggressive Link Power Management (ALPM) feature to mostly power the SATA connection is usually sufficient to put a drive to sleep. But the lowest-power sleep state supported by SATA devices (DevSleep) requires extra signalling on a pin that's part of the SATA power connector. This means that DevSleep is in practice only supported on laptops, and our desktop testbeds cannot use or measure this sleep state.

NVMe includes numerous features pertaining to power management or thermal management. Most of them are optional in the NVMe spec, but there's a common subset supported by most consumer SSDs. NVMe drives can support numerous different power states, including multiple active and multiple inactive power states. The drive's firmware provides information about its capabilities to the host system:

Samsung 980 PRO
NVMe Power States
Controller Samsung Elpis
Firmware 1B2QGXA7
Power
State
Maximum
Power
Active/Idle Entry
Latency
Exit
Latency
PS 0 8.49 W Active - -
PS 1 4.48 W Active - 0.2 ms
PS 2 3.18 W Active - 1.0 ms
PS 3 40 mW Idle 2.0 ms 1.2 ms
PS 4 5 mW Idle 0.5 ms 9.5 ms

 

When a drive and the host OS both support the Autonomous Power State Transition (APST) feature in NMVe 1.1 or later, the host system can give the drive a set of rules for how long it should wait while idle before dropping down to a lower-power state. Operating systems choose these delays based on the power state entry and exit latencies claimed by the drive, and other configuration information about the system's overall tolerance for increased disk access times.

One common problem with the NVMe APST feature is that the NVMe spec doesn't really say anything about how APST interacts with PCIe Active State Power Management. SSD vendors tend to make assumptions that eg. a system which configures the drive to use its deepest idle state will fully support PCIe APSM. Most of the time, things work out, but it's also possible to end up with a drive that goes to sleep and never wakes up, or a drive that defaults back to its highest power state if anything goes wrong when it tries to go to sleep.

Using our Coffee Lake testbed that has fully functional PCIe power management, we test SSD power in three states. Active idle is when the drive is not using any externally-configurable power management features: SATA or PCIe link power management is disabled, and NVMe APST is off. We're now using a more reliable and broadly-compatible method for disabling APST through the Linux kernel rather than directly poking the drive's registers. This means that some drives will probably end up showing higher active idle power draw than we have previously measured.

Even though there are many combinations of power management settings and power states that can be used with a typical consumer NVMe SSD, we condense it down to just two low-power configurations to test. What we call "Desktop Idle" is using the features that are almost always available and working on desktop platforms, even if they're off by default. This includes enabling SATA ALPM, NVMe APST, and PCIe ASPM.

Next, we have the "Laptop Idle" state, with all the power-saving features fully enabled. For SATA SSDs, this would include DevSleep, so we can't fairly measure the Laptop Idle power draw of SSDs. For NVMe SSDs, this includes enabling PCIe L1 substates.

Idle Power Consumption - No PMIdle Power Consumption - DesktopIdle Power Consumption - Laptop

Accurately measuring the time it takes for a drive to enter a low-power state is tricky, but measuring the time taken to wake up is straightforward. We run a synthetic test that performs a single 4kB random read once every 10 seconds. When power management features are disabled and the drive stays in its active idle state, the random read latency will be determined mainly by the speed of the NAND flash. When the drive is in the Desktop Idle or Laptop Idle state, it will go to sleep between each random read, so we can repeatedly sample the time taken to wake up and perform a random read. The difference between this time and the random read latency from the drive in the active idle state is due almost entirely to the overhead of waking up the drive from a sleep state, and this difference is what we report as a drive's wake-up latency.

Idle Wake-Up Latency

 

Conclusions

In this article we hope we've given you an insight into how much goes into testing a modern solid state storage drive - something more than just running CrystalDiskMark and finding peak sequential speeds! The new suite is not only more in-depth, but also we've streamlined it somewhat for automation, enabling fewer sleepless nights as deadlines loom on the horizon (or put another way, more reviews to come). We're obviously keen to take on additional feedback with the testing, so please leave a comment below.

Advanced Synthetic Tests: Block Sizes and Cache Size Effects
Comments Locked

70 Comments

View All Comments

  • Billy Tallis - Monday, February 1, 2021 - link

    I set up the testbed with an old 5450 I had lying around, and once all the software was configured I pulled the GPU back out. (That ancient GPU interferes with suspend, which is needed to unlock drives so they can be secure erased.) The system boots without complaint with no GPU, and I use SSH and RDP to run the tests. I'm keeping the 580 in the other system for now because I want to work on getting some application or gaming tests working on that machine when I have spare time.
  • Billy Tallis - Monday, February 1, 2021 - link

    I should mention that I have had a bit of trouble booting the ASRock B550 Pro motherboard, because it seems to have half-assed UEFI boot support. The motherboard will forget its boot settings at the slightest provocation, and when that happens it will search for and boot the first Windows it can find. It refuses to detect a Linux bootloader on an internal drive, even if it's in the canonical EFI/Boot/bootx64.efi location on the ESP. So any time this machine decides to forget its boot settings, I have to plug in a GPU and keyboard and boot a Linux off a USB device to re-create the UEFI boot entry for grub.
  • DominionSeraph - Monday, February 1, 2021 - link

    This is the power of AMD.
  • Billy Tallis - Monday, February 1, 2021 - link

    On the other hand, I was quite surprised to discover that a quad M.2 riser works on this board. Intel would never let PCIe bifurcation be enabled on an entry-level motherboard.
  • Slash3 - Wednesday, February 3, 2021 - link

    Asus actually bundles a quad NVMe M.2 adapter with their Strix B550-XE, for some absolutely baffling reason. I tried asking the Asus technical marketing rep on Reddit why they did this, but he didn't understand the question. What a weird friggin decision.

    https://rog.asus.com/us/motherboards/rog-strix/rog...
  • frbeckenbauer - Tuesday, February 2, 2021 - link

    I have had the same issue on my old ASRock intel board, on my current MSI AMD board, on my Intel laptop, and on my AMD laptop. People really like writing UEFIs that just randomly boot a windows they find for no reason
  • kepstin - Tuesday, February 2, 2021 - link

    I've seen a few AMD boards that have bios options to enable headless operation - basically, setting that option disables the post check for the graphics card. If you're running in native UEFI mode and your operating system doesn't require a GPU, it'll work fine.
  • Makaveli - Monday, February 1, 2021 - link

    This was a great article thank you Billy!
  • WaltC - Monday, February 1, 2021 - link

    Nice write up...;) Seems rather unsurprising that the two PCIe4 drives running in PCIe4 mode (I gather from the test hardware described) were the best overall performing in your tests. Although you described the PCIe/SATA interfaces of most of the drives--I wasn't clear on the Mushkin or the MP400. Also, a more thorough description of the drivers employed would help--open source or proprietary, etc. Linux distro tests, however, would seem to me to be of somewhat less "practical" value than Win10 tests--considering that Win10 is where the overwhelming bulk of these drives will be deployed by the consumers who buy them, I would think. Overall, it's nice to see changes here in AT's testing methodology!
  • evilspoons - Monday, February 1, 2021 - link

    Nice to see another substantial benchmark upgrade, keeping up with this stuff can be mind-boggling at times.

    The article could use someproofreading though. Even just the first paragraph:
    "on accident" -> by accident
    "holy unified metric" -> wholly-unified metric

    Unless religion is somehow involved in benchmarking SSDs 😉

Log in

Don't have an account? Sign up now