Power
NVMe SSD Idle Power: Active States, Return Latency and Daily Energy
Compare an SSD's idle watts with its ability to serve I/O, the power and duration of active work, and the requests that arrive after a return transition. Energy accumulates over time in each condition; response depends on what happens to each request. Two access patterns can therefore have equal total idle hours and different numbers of requests encountering a return delay. A non-operational idle figure establishes neither sustained-read consumption nor the installed server's active cooling requirement.
Idle and operational describe different things
Idle describes the absence of work under stated conditions. Operational describes whether the controller can process I/O in a power state. An operational drive can therefore be idle between requests; the word idle alone does not identify a non-operational state.
Microsoft's nvme.h reference makes the capability explicit through NOPS: zero means the controller processes I/O in that state; one means it does not. For a non-operational-state headline, useful I/O requires a return to an operational state.
Non-operational also does not mean that every controller function is off. The historical NVMe 1.4c specification permits administrative and register activity and describes qualified background-power exceptions. Its distinction concerns I/O processing, not an unconditional promise of zero activity or constant draw.
For an offer comparison, first identify which state produced the advertised idle figure. A low value for a state that cannot serve requests answers a different question from consumption while the drive is ready to handle them.
Read the power quantity before comparing the watts
Microsoft distinguishes three descriptor quantities. MP is maximum NVM-subsystem power in the state; NVMe 1.4c specifies a sustained maximum. IDLP is typical idle power averaged over 30 seconds after ten seconds idle. ACTP reports the largest average over a ten-second window during the workload identified by the Active Power Workload (APW) field. If that workload finishes sooner, NVMe 1.4c specifies averaging over its duration. Their associated scale fields determine the watt conversion.
IDLP or ACTP equal to 0000h means the corresponding power is unreported. NVMe 1.4c also defines zero MP as unreported. These zeros are not observations of zero consumption.
These definitions explain why a proposal's unqualified power column is insufficient. Establish whether it contains maximum state power, an idle quantity, workload-specific active power or a supplied observation. Keep its conditions attached. An active-power average is not an instantaneous peak, and the idle quantity does not become an active-workload result because both are expressed in watts.
Return latency has its own clock
The nvme.h ENLAT and EXLAT fields report maximum entry and exit latency in microseconds. They describe transitions, rather than measured completion of an application read. NVMe 1.4c defines zero in either latency field as unreported, not an instantaneous transition.
NVMe 1.4c distinguishes the old state's exit from the destination state's entry when describing a transition's maximum duration. Consequently, copying one exit field into a proposal as exact first-request latency loses both its maximum qualification and the remainder of the request path.
Microsoft's June 12, 2023 StorNVMe guidance provides a named implementation example. Its runtime idle-state selection considers idle timeout, transition-latency tolerance and system state; eligibility uses ENLAT plus EXLAT. That Windows driver policy is not a universal enterprise NVMe policy or a statement of the buyer's installed behavior.
The buying question is whether supplied response evidence covers requests after the relevant idle interval, as well as requests during active operation. An already-active latency result leaves the return from a low-power state unresolved.
Eight fictional drives: 8 W idle, 80 W active, 480 Wh per day
Stipulate eight hypothetical drives. Each consumes exactly 10 W throughout four hours of active work and exactly 1 W throughout twenty hours idle every day. All eight drives follow the same active and idle schedule. Ignore transitions, background activity and all other components. These are invented constant inputs, independent of any product descriptor or measured server.
For each drive, the active period consumes 10 W x 4 h = 40 Wh. The idle period consumes 1 W x 20 h = 20 Wh. Together they consume 60 Wh per day. Eight drives therefore consume 8 x 60 Wh = 480 Wh, or 0.48 kWh, per day under these assumptions.
The eight-drive group draws 8 W during the stipulated idle period and 80 W during the stipulated active period. Applying 8 W to all 24 hours would give 192 Wh and omit the extra active consumption. Applying 80 W to all 24 hours would give 1,920 Wh and omit the stipulated lower idle draw.
Dividing 480 Wh by 24 h gives a fictional daily average of 20 W for the drives. That average still leaves an 80 W active interval. It does not reduce that interval to 20 W or establish any actual server load. CPUs, memory, networking, fans and conversion losses were excluded from the example.
The arithmetic illustrates a duty cycle, not an idle policy. It supplies neither the fraction of time a real drive spends in each state nor the facility's cooling allowance.
Equal active service time can hide different return delays
Consider a separate fictional comparison of drives A and B. For one request arriving while each drive is already in its stipulated non-operational state, assume exact total resume delays of 2 ms for A and 20 ms for B. After resuming, either drive takes exactly 0.8 ms to serve the request. Assume the delays occur consecutively, with no queueing or other overhead.
A's stipulated request duration is 2 ms + 0.8 ms = 2.8 ms. B's is 20 ms + 0.8 ms = 20.8 ms. Looking only at their identical 0.8 ms active service time would conceal this difference.
Here, resume delay is an invented total delay before service, not a copied EXLAT maximum. The example neither predicts a product's response nor assigns the same penalty to every request. If a request arrives while its drive is already operational, these stipulated sleeping-drive delays do not describe that arrival.
A longer idle interval and repeated short gaps can consequently present different buying questions even when their total quiet time matches. The relevant evidence needs to show which requests encounter a return transition. The arithmetic cannot determine when a real system chooses a state or how often that transition occurs.
Equal idle hours can put different requests through a return transition
Now connect the two examples by changing only the arrangement of the fictional day. Keep the eight drives, 10 W active and 1 W idle, with four active hours and twenty idle hours per drive. Schedule L has one twenty-hour quiet interval followed by four active hours. Schedule S repeats a ten-minute quiet interval and a two-minute active interval 120 times. Both schedules account for exactly 24 hours.
For this illustration, stipulate that each drive is already in the same non-operational state whenever its quiet interval ends. One first request arrives at the start of each active interval. Other active work is left unspecified. Ignore transition duration and transition energy in the time-and-energy account, as in the earlier constant-power example. These assumptions describe a mathematical comparison, not a platform policy or a reproducible test.
Under that account, each drive still has 20 Wh idle plus 40 Wh active, and the eight-drive group still has 480 Wh per day. The first-request counts differ: one per drive in L, 120 per drive in S. The equal time totals have not identified how many requests encounter a return transition.
The earlier 2.8 ms and 20.8 ms request durations explain why that distinction matters when a return delay is present. They do not establish response percentiles for either schedule: the remaining request population and its timing were not specified. Nor does the equal modeled energy predict equal real energy, because actual transition costs, state residence, background work and policy behavior were left out.
A useful proposal comparison therefore needs two kinds of workload evidence. Time in the applicable states supports the energy calculation. Requests arriving after the relevant gaps support the response comparison. An idle-hours total cannot stand in for both.
Scroll the table horizontally on smaller screens.
| Schedule | Idle time per drive | Active time per drive | First requests per drive after quiet intervals | Source |
|---|---|---|---|---|
| L: one long gap | 1 × 20 h = 20 h | 1 × 4 h = 4 h | 1 | Planning analysis |
| S: repeated short gaps | 120 × 10 min = 1,200 min = 20 h | 120 × 2 min = 240 min = 4 h | 120 | Planning analysis |
All state occupancy, first-arrival and constant-power conditions are stipulated. Transition duration and energy are excluded from this illustrative account; no actual drive or policy behavior is established.
Separate the drive state, PCIe link and whole system
PCIe Active State Power Management, or ASPM, concerns link power states. NVMe controller power states concern the storage device. Whole-system sleep is another layer. NVM Express's technology overview distinguishes these layers and explains that an SSD can enter a low-power idle state while its host system remains working.
A claim about a PCIe L1 substate therefore does not by itself identify the controller's NVMe state. Likewise, a sleeping-drive figure does not describe the whole server asleep. For a quoted low-power result, identify which layers and measurement boundary were included before comparing it with another result.
This matters particularly when a headline comes from a quiet client-use example but the proposed server must sustain storage traffic. Transfer the documented conditions with the number; the common NVMe label cannot make those operating circumstances equivalent.
Choose for the actual access pattern
For sustained reads, assess the applicable I/O-capable state and power evidence for that work. A non-operational idle figure cannot establish consumption throughout the read interval because that state does not process the required I/O. It also cannot supply an active thermal envelope for the installed system.
For intermittent access, idle consumption becomes useful alongside the length and frequency of quiet periods and the required response after them. A drive with a lower advertised idle value has not established a lower daily energy total if the real system seldom reaches that condition. Nor has it established acceptable response for the first request after a gap.
Have the storage and platform owners reconcile the exact drive and capacity variant, firmware applicability, supported states, effective platform policy and workload evidence. Use the daily-energy example to ask about time in each state, then the two schedules to ask which requests arrive after a return transition. Those are related questions with different required evidence.
The related storage-performance guide explains how to compare latency statistics and workload boundaries. The server-power guide addresses the separate jump from a component claim to complete-system input. Configuration decisions and system power, thermal and compatibility evaluation remain with their appointed owners.
Connect the selected system to its physical installation
Once the responsible owners have selected the equipment, use Leviathan's GPU Infrastructure Physical Installation service and project inquiry below to discuss customer-supplied equipment mounting, approved physical interconnects, labeling and installation records.
Share a nonconfidential equipment summary, approved mounting and connection requirements, site location and required handoff records. The agreed work package defines the permitted physical tasks; SSD power-policy tuning and thermal commissioning remain with the appointed specialists.
References: [L1]
Primary sources
- [M1] Microsoft Learn: NVME_POWER_STATE_DESC structure (nvme.h)Checked 2026-10-20. Updated March 13, 2023. Defines state capability, power quantities, reporting scales and maximum transition latencies.
- [M2] Microsoft Learn: NVMe power management for storage hardware devicesChecked 2026-10-20. Updated June 12, 2023. StorNVMe runtime policy is a Windows-specific example; its defaults do not establish another platform's behavior.
- [N1] NVM Express Base Specification, Revision 1.4c: power-state descriptors and power managementChecked 2026-10-20. Historical revision; cover dated March 9, 2021. Figure 252, printed page 194, and section 8.4, pages 320–321, explain unreported fields, transition components and non-operational-state scope.
- [N2] NVM Express: Technology Power FeaturesChecked 2026-10-20. Architecture overview distinguishes drive, PCIe and system states and discusses duty cycle. Historical product examples are not adopted.
- [L1] Leviathan Systems: GPU Infrastructure Physical InstallationChecked 2026-10-20. Existing customer-supplied equipment mounting, physical interconnects, labeling and installation-record scope; actual work is engagement-defined.