Idle Power Draw: Measuring What Your Rack Really Costs

Every hardware review measures the wrong thing. They run a benchmark, they log the peak, they publish a bar chart of watts under full load, and everybody buys the machine that wins. Meanwhile your rack spends roughly 23 hours a day doing almost nothing: a handful of containers ticking over, a Postgres instance with four connections open, a reverse proxy waiting for a request that arrives every ninety seconds. That idle state writes your electricity bill, and almost nobody measures it before they buy.

I worked this out the expensive way. A machine I was fairly proud of turned out to be drawing 78 W to run a DNS resolver and a status page. At Danish electricity prices that is a not-small annual sum for the privilege of resolving mylab.local slightly faster than a Raspberry Pi would. The fix was measuring, believing the measurement, and then deleting the parts of the setup that could not justify themselves.

Why idle dominates the arithmetic

The maths is embarrassingly simple, which is probably why it gets skipped. A device drawing a constant W watts for a year consumes W × 8.76 kWh. Every single watt of idle draw therefore costs you 8.76 kWh per year, forever, whether or not the machine did anything useful with it.

Put a price on it. At €0.30/kWh — a rough European figure with distribution and tax included, and Danish households have seen considerably worse — one watt costs about €2.63 a year. That gives you a mental conversion rate worth memorising:

1 W idle ≈ €2.60/year ≈ €26 over a ten-year life.

Now the numbers get interesting. That 78 W box costs roughly €205 a year to keep switched on. A modern N100-class mini PC idling at 7 W costs €18. The difference — €187 a year — buys the mini PC outright in about four months, and then keeps paying you.

Peak draw barely enters into it. Suppose your server hits 140 W under load, and load happens for twenty minutes a day. That is 140 W × 0.33 h × 365 = 17 kWh/year, about €5. The peak figure that dominates every review is worth five euros. The idle figure that nobody publishes is worth two hundred. This is why “it only pulls 140 W flat out, that’s fine” is one of the more expensive sentences in the hobby, and it is the same arithmetic underneath the real cost of self-hosting.

There is a second-order cost people forget: heat. Every watt you consume is a watt you dump into the room, and in a flat that means either an open window in February or an air conditioner in July working at a coefficient of performance around 3. Cooling 100 W of waste heat costs you another 33 W of compressor for whatever part of the year you are cooling. It is a small tax on an already bad number.

Measuring it properly

You need a meter. Estimating from PSU ratings, TDP figures or the number printed on the sticker is astrology. A 550 W PSU tells you the maximum the supply can deliver, which correlates with actual consumption about as well as your car’s speedometer top marking correlates with your commute.

Three tiers of instrument, in increasing order of usefulness:

A cheap plug-in energy meter. Twenty euros, plugs between the socket and the kit, shows instantaneous watts and cumulative kWh. Good enough for 80% of decisions. The catch: accuracy at low draw is poor. Many are specced ±2 W or worse below 30 W, which is fine for a kettle and useless for a mini PC pulling 7 W. Read the datasheet before you trust a low reading.

A smart plug with energy monitoring. Same job, but it reports over the network, so you can log it and look at it later rather than crouching on the floor with a torch. Devices built around the common energy-monitoring chipsets tend to be honest down to about 1 W. If you already run Home Assistant tracking what your home lab actually costs, this drops straight into it.

A metered PDU. Per-outlet measurement for the whole rack, which is the only way to attribute draw to individual machines without unplugging things. Expensive new, occasionally sane secondhand. Overkill for four devices, transformative for fourteen.

Whatever you use, measure at the wall. Software readings from powertop or RAPL counters tell you what the CPU package thinks it is consuming, which excludes the PSU’s conversion losses, the drives, the fans, the NIC, and the motherboard’s own overhead. The wall figure is the one your utility bills you for. On a machine with a mediocre 80+ Bronze supply at low load, the wall figure can run 25–30% above the sum of the component figures, because cheap PSUs are dreadful at converting 30 W of the 550 W they were designed for.

Getting a number you can trust

An instantaneous reading lies. Fans spin up, a backup job fires, a scrub kicks off, and you happen to look at the display during the one interesting minute of the hour. What you want is the median over a representative period, plus the total kWh over a week.

The energy counter is the honest one. Note the kWh reading, wait seven days, note it again, and divide:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Average draw over a measured window, from two cumulative kWh readings.
# start: 14.207 kWh, end: 15.981 kWh, 7 days apart
python3 - <<'PY'
start_kwh = 14.207
end_kwh   = 15.981
hours     = 7 * 24

avg_watts = (end_kwh - start_kwh) * 1000 / hours
print(f"average draw: {avg_watts:.1f} W")
print(f"annual kWh:   {avg_watts * 8.76:.0f}")
print(f"annual cost:  EUR {avg_watts * 8.76 * 0.30:.0f}")
PY

1
2
3

average draw: 10.6 W
annual kWh:   93
annual cost:  EUR 28

Seven days catches your weekly rhythm — the Sunday backup window, the nightly container pulls, the Saturday afternoon where you actually use the media server. A five-minute spot reading catches none of it.

If you are logging to Prometheus already, the same idea expressed as a query gives you a rolling figure and, more importantly, a graph you will actually look at:

1
2
3
4
5

# Rolling 7-day average draw per machine, in watts
avg_over_time(smartplug_power_watts{device=~"node.*"}[7d])

# Annualised cost in EUR at 0.30/kWh
avg_over_time(smartplug_power_watts{device=~"node.*"}[7d]) * 8.76 * 0.30

Stick both on a dashboard next to your uptime panels. A number you see daily gets acted on; a number in a spreadsheet gets forgotten. The general principle is the one from Grafana and Prometheus: a monitoring stack that scales down — instrument the thing you intend to change.

Where the watts actually go

Once you start measuring individual components rather than whole machines, the culprits become repetitive. In rough order of how often they surprise people:

Spinning disks. A 3.5" drive costs 4–8 W spinning, and around 1 W in standby. Six drives idle-spinning is 30–45 W — €80 to €120 a year — for a pool that gets read twice a week. Spin-down is contentious (head parking cycles wear the drive, and a filesystem with atime enabled will keep waking them anyway), and I have made peace with the trade-off on bulk archive pools while leaving the working set on SSD. Anything that stops routine metadata reads from waking the whole array pays for itself twice: once in latency, once on the bill. It is one of the quieter arguments for the layout in ZFS for mortals.

The PSU. An oversized supply running at 8% load operates far outside its efficiency sweet spot, which is typically 40–60% of rated output. Swapping a 750 W unit for a decent 400 W one on a machine that peaks at 180 W has, in my experience, been worth 8–12 W at idle. The 80+ rating on the box is measured at 20/50/100% load; nobody publishes the 5% figure, and the 5% figure is where your server lives.

Enterprise NICs and HBAs. A 10G SFP+ card with copper transceivers can burn 6–10 W doing nothing at all — the transceivers themselves are 2–3 W each. Fibre optics or DAC cables cut that substantially. An HBA in IT mode is another 8–12 W of constant heat, whether or not any drive attached to it is awake.

C-states that never engage. This is the quiet one. A machine that should idle at 8 W idles at 22 W because something — a USB device polling, a NIC with ASPM disabled, a poorly-behaved PCIe card, an aggressive BMC — keeps dragging the CPU package out of its deep sleep states. The hardware is capable of the low number and never reaches it.

1
2

# Where is the package actually spending its time?
sudo turbostat --quiet --show PkgWatt,Pkg%pc2,Pkg%pc3,Pkg%pc6,Pkg%pc8,Pkg%pc10 --interval 5

If Pkg%pc8 and Pkg%pc10 are near zero on a machine that supports them, you have found several free watts. powertop --auto-tune will fix some of it, and will also, occasionally, disable the USB controller your keyboard is attached to. Ask me how I know.

Troubleshooting the numbers that don’t add up

The meter reads lower than the components should. Almost always a meter accuracy problem at the bottom of its range. Cross-check by adding a known load — plug a 40 W lamp into the same meter and confirm it reads 40 W. If it reads 34 W, everything else it has told you is 15% optimistic.

Idle draw is 15 W higher than an identical machine. Compare BIOS settings before you compare anything else. Some vendors ship with C-states limited, ASPM off, or a “performance” power profile as the default, and the delta between a default BIOS and a tuned one on the same silicon is regularly 10–20 W. The BMC is another suspect: an out-of-band management controller is a small always-on computer costing 5–8 W, and on a machine that lives in the same room as you, that is a service you may be paying for and never using.

Draw climbs slowly over weeks. Dust. Fans compensating for restricted airflow spin faster and pull more; the fans in a neglected 2U chassis can account for 15 W on their own. It is also worth checking whether a container has developed a busy-wait loop — a process spinning on a poll with no sleep will pin one core awake permanently and block every package C-state on the machine. powertop’s wakeup list finds these in about thirty seconds; anything above a few hundred wakeups per second on an idle box deserves an explanation.

The graph has a step change you can’t explain. Correlate it against your own change log before you blame the hardware. A kernel upgrade that regressed a driver’s power management, a firmware update that reset the BIOS profile, and a container that started pinning a core are all far likelier than a PSU degrading. This is one of the cases where boring records beat clever debugging.

Everything measures fine but the bill doesn’t move. Check what else is on the circuit. I once spent a fortnight optimising 12 W out of a rack while a chest freezer in the same room cycled at 90 W average and made the whole exercise statistically invisible.

The verdict

Measuring idle draw is the highest-leverage hour you will spend on your homelab, and it costs about €20 of meter. The exercise regularly finds 30–50% of a rack’s consumption sitting in components that could be removed, replaced or configured differently, and unlike most optimisation, the saving recurs every year without further effort.

What it will also do, if you are honest, is force an uncomfortable conversation about whether the rack should exist in its current shape at all. My own measurement exercise ended with two machines going on the secondhand market and their workloads consolidating onto one mini PC that idles at a tenth of the draw — roughly the conclusion of the home lab upgrade trap arrived at from the other direction. That 78 W box was doing about 6 W of actual work with a great deal of ceremony wrapped around it.

Who should skip this? Anyone whose electricity is included in the rent, and anyone running a genuinely loaded cluster where average utilisation is high enough that idle becomes a rounding error. For everyone else — which is nearly everyone, because homelab utilisation is dismal by design — go and buy the meter. The number will annoy you, and being annoyed by a number is the cheapest motivation available.