A protocol for measuring power draw

Anyone can write down “about 60 W”. The hard part is making sure the next person who measures gets the same 60 W.

The short answer

A measurement protocol is a written recipe: freeze the configuration, measure each operating state on its own, repeat the run, and keep every setting next to the numbers. This one is deliberately lightweight. It borrows ideas from established test methods (SPEC’s SERT and ENERGY STAR) and is not a certified result of either.

How it works

1. Freeze the configuration. Before the first reading, write down hardware, firmware, operating system, power profile, active power supplies, network and attached devices. SPEC asks the same of testers who run its server efficiency tool (SERT): any deviation from the default configuration has to be documented well enough that an independent party could reproduce it, and nobody may intervene during a measurement run.
2. Record the setup. Note the meter model, the measurement boundary (see the article on measurement boundaries), the input voltage and the room temperature. SPEC says temperature often has a substantial, non-linear effect on power draw, and its SERT validity checks require the line voltage to stay within 5 % of the standard value and the temperature to stay at 20 °C or above. A home protocol doesn’t have to enforce those limits, but it should record what they were.
3. Warm up, then measure. SERT runs a warm-up phase first. Inside every interval it also keeps a pre-measurement period so the system can reach steady state, and only the recording period counts toward the result. Do the same: wait until the readings settle before you start the clock.
4. One state at a time. The ENERGY STAR test method for computers measures sleep, long idle, short idle and off mode separately. Its final draft from November 2024 also capped the wait after the last user input before measuring starts: 5 minutes for short idle, 20 minutes for long idle. The final version from January 2025 no longer contains that cap in its test conduct section; it hands the measurements to the international standard IEC 62623 (Edition 2.0, 2022), which we have not read. The final criteria define the two idle states by time after boot, after a workload or after sleep: 5 minutes for short idle, 15 minutes for long idle. Those are definitions, not the draft’s waiting caps. Treat 5 and 20 minutes as a draft rule, not as current requirements. SERT also keeps idle apart. Its idle workload leaves the system ready to work but doing nothing, and it produces no performance score. This protocol uses four states: off or standby, settled idle, a representative workload of your own, and optionally a controlled load.
5. Summarise every state the same way. Give the duration, the minimum, the median, the maximum and the number of runs. Keep the raw readings next to the summary.
6. Repeat. SPEC cites a study of run-to-run differences in SERT: from 0.7 % (0.1 W on the system tested) for the idle worklet up to 4.0 % (1.32 W). One run is a sample, not the truth.
7. Don’t stretch the result. SPEC states that the AC power its tool measures should not be assumed to represent the power of other applications on the same hardware. Say which workload you ran, and don’t call your numbers a SERT or ENERGY STAR result.

In practice

Five assumed readings from one state, in watts: 121.0, 121.4, 120.8, 121.2 and 148.9. A background job started during the last reading.

minimum  120.8 W
median   121.2 W
maximum  148.9 W
mean     126.7 W   (126.66 W)

The mean is pulled up by the one outlier, the median isn’t. That is why the protocol asks for minimum, median and maximum, plus a note about what happened. The header of a protocol sheet can be this short:

Configuration:  model, CPU, memory, drives, number of power supplies,
                firmware version, operating system, power profile
Setup:          meter model and range, boundary, input voltage, room temperature
State:          off | settled idle | own workload | controlled load
Timing:         warm-up time, recording time, number of runs
Result:         minimum / median / maximum
Deviations:     anything that differed from the plan

The five readings are made up for illustration; they are not measurements. Where this comes from: we first wrote the protocol for HomelabWatt, a tool project we no longer pursue. The method doesn’t depend on it.

Keeping the sheet: one table, append only

The protocol is only as useful as the file it lands in. Keep one table per machine (a CSV in the repository is enough) with one row per state and run, and never edit old rows: a corrected value gets a new row with a note, so the history stays readable. Columns that have earned their place: date, state, configuration ID (a short tag that points to the frozen configuration block), meter, boundary, input voltage, room temperature, warm-up and recording minutes, runs, minimum, median, maximum, deviations. When two rows for the same state and configuration differ by more than the meter’s stated uncertainty, something changed that you did not write down. Find it before you trust either row.

Reading someone else’s number

Before you compare your result with a figure from a forum or a vendor page, ask the protocol’s own questions of it: which boundary, which state, which power profile, how long, how many runs, which meter? A number that cannot answer at least boundary and state is not comparable with yours, however precise it looks. That is also why we publish our own values only with the header block above.

Checklist

• Freeze the configuration and write it down before you start. Don’t change anything during a run.
• Record the meter, the measurement boundary, the input voltage and the room temperature.
• Wait until the readings settle before you start recording each state.
• Measure every state on its own and give it a name.
• Report minimum, median and maximum for each state, not just an average.
• Repeat each state at least once, or label the result clearly as a single run.
• Write down every deviation and every background job you noticed.
• Name the workload you ran, and don’t claim a certification you don’t have.
• Keep one append-only table per machine, and investigate rows that disagree by more than the meter’s uncertainty.