Power Consumption: Now With DevSlp Testing
Sometimes I find it unfortunate that most of our storage analysis is in the context of desktop PCs, where the power consumption of an SSD doesn't really matter. The topic is far more meaningful in the enterprise and mobile spaces though, so I find it critically important to benchmark power thoroughly and as precisely as possible.
On a laptop, every milliwatt matters. So much so, in fact, that Intel's Haswell-based CPUs and corresponding chipsets on the mobile side support a new mode for reducing SSD power consumption. DevSlp, or device sleep, is a sideband signal sent to the storage device to indicate that it should drop into a super-low power state. Essentially, everything that can be off is.
This is a great way to get a little extra battery life out of an Ultrabook (particularly in light of Intel's targets for runtime and standby connectivity). But you do pay a price: it takes longer to enter and exit the DevSlp state. Granted, the delay is less than powering the SSD down and back up as needed, a process that can take seconds. Worse, an drive may use substantial amounts of power as it's readied again. DevSlp should need only 50 ms in contrast, along with a few milliwatts.
To measure power consumption in a DevSlp state, we need two things. First is an Ultrabook with a Haswell-based CPU on a compatible platform. I'm using Lenovo's ThinkPad T440s. It's reasonably versatile, including a 2.5" SATA bay and two M.2 slots (for M.2 2242s) wired to the PCH's SATA ports. I typically don't need more than one slot, but it's nice to have the option at least.
The second item is a test platform able to initiate the DevSlp command, measure the current draw, and record the results. To do that, ULINK Technologies sent over some hardware designed expressly for this purpose. I've been using the company's DriveMaster software and SATA/SAS power hubs for a year now, and they confer a spectacular amount of control over what drives under test do. In this case, DevSlp testing is made possible in a way that's informative and easy to manage.
Using a test script to record amperage and issue the appropriate commands, this is what we end up with:
This is an example from my Plextor M6S review. The test script begins at active idle, then issues write commands (the first big increase in power). After 20,000 I/Os, the drive gets issued the DevSlp signal (denoted by the vertical purple bars). In this DevSlp zone, it takes a few tens of milliseconds before the drive enters DevSlp as commanded, but it stays at the state using just 2.5 mW until DevSlp exits (noted by the second purple bar). More I/O is then issued, and then it's back to idle before the script ends. The results are recorded in milliamps, and I convert to watts.
DevSlp State Testing
This is what we end up with when we apply the same methodology to Transcend's SSD340. It draws considerably more power than the M6S when it drops into DevSlp. That's 2.5 mW from Plextor and 53 mW from Transcend. Under 5 mW is what we're looking for.
Elsewhere, we observe 3.03 W maximum consumption in the script, with active idle settling at 0.444 W (or about one-sixth of the maximum).
We can also sort power use in slumber and partial slumber states. These are mostly important for mobile applications. On the desktop, you'd want to turn them off since it takes time to transition from power-saving to active states. The deeper the sleep, the more delay is incurred getting back.
Here are some results for a couple of other SSDs:
Sadly, the SSD340 really does use more power in DevSlp (like ten times as much). After a lot of head-scratching and retesting, I can confirm these numbers are accurate on my Lenovo T440s test rig.
I'm not particularly worried though. This is only important news if you're upgrading an Ultrabook with a Haswell-class processor in it. And in that subcategory, there are few platforms with 2.5" SATA bays. Lastly, 53 mW still isn't much.
