Why Your Homelab Burns 300W Doing Nothing

Plug a power meter into the wall feed of a typical homelab rack and you will see a number that does not move much: 280, 300, maybe 350 watts, around the clock, whether anyone is using anything or not. The services are idle. The VMs are idle. The disks are serving nobody. And yet the rack draws as much continuous power as four or five refrigerators. At 300W continuous, you are buying 2,628 kWh per year — roughly $394 at a cheap US rate of $0.15/kWh, and over $1,100 at German residential prices. That is real money spent on machines waiting for work that mostly never comes.

The frustrating part is that almost none of that 300W is doing anything you would miss. It is the residue of decisions that were rational for a datacenter and irrational for a closet: enterprise servers tuned for throughput instead of idle efficiency, oversized power supplies running at the worst point of their efficiency curve, a NIC blocking the entire CPU package from sleeping, and three machines doing what one mini-PC could do. This post is about dismantling that 300W methodically — understanding where each watt goes, which knobs actually move the meter, and which “optimizations” are folklore.

The Anatomy of an Idle Watt

Before optimizing anything, you need to know where the power goes. Here is a representative breakdown of a 300W-idle homelab — not exotic, just the standard “eBay enterprise gear plus accumulated machines” build that thousands of us have assembled:

Where 300W of idle goes (typical accumulated homelab)
======================================================================
Dell R720 (2x Xeon E5, 8x 3.5" HDD)  ##############################  130W
Whitebox Xeon E3 (Plex, backups)     #############                    55W
Old desktop as NAS (4x 3.5" HDD)     ##########                       45W
24-port enterprise PoE switch        ########                         35W
PoE cameras + APs (4 devices)        #####                            20W
Modem, router, Pi, UPS conversion    ###                              15W
                                                            -----------
                                                            total: 300W

Each of those lines decomposes further, and the per-device numbers are remarkably consistent across hardware generations:

Two structural effects amplify all of this. First, PSU efficiency at low load. The 80 Plus certification levels (Bronze through Platinum) test at 20%, 50%, and 100% load — there is no requirement at all below 20% for most tiers (only Titanium adds a 10% test point). A server with a 750W supply idling at 60W is running at 8% load, where efficiency commonly collapses to 60–70% or worse. That means for every 60W the components consume, you pay for 85–100W at the wall. Redundant supplies make it worse: two PSUs splitting a 60W load each run at 4% of rating, each with its own fixed overhead of fans, standby circuitry, and conversion loss.

Second, conversion stacking. Wall AC → UPS (double-conversion units burn 10–15% continuously) → server PSU → motherboard VRMs → device. Every stage taxes the watt before it does work. If you run an online double-conversion UPS for a homelab, that alone can cost 20–40W around the clock — worth considering when you size backup power, which I cover in the UPS sizing and NUT guide.

Why Enterprise Gear Idles Hot

People are often surprised that a decommissioned server idles at 100W+ when their gaming desktop idles at 40W. It is not age alone — it is design intent.

Enterprise servers are engineered for a world where they run at 40–80% utilization in a rack of identical machines, where a watt of idle savings matters less than a microsecond of wake latency. The consequences:

• C-states are sandbagged by default. Server BIOS profiles (“Performance,” “Maximum Performance”) frequently cap package C-states at PC2 or disable C-states entirely, because waking from C6 costs tens of microseconds and datacenter operators care about tail latency. Your Jellyfin server does not.
• ASPM is often unimplemented or disabled. Server NICs, SAS HBAs, and backplanes are built assuming the PCIe links never sleep. A common LSI SAS HBA simply does not support ASPM, which (as we will see) caps how deep the whole CPU package can sleep.
• Everything is duplicated. Dual PSUs, dual fans, a BMC that is itself a small always-on computer. The iDRAC/iLO draws 5–15W whether the host is on or off.
• The platform is sized for maximum configuration. 24 DIMM slots, multiple 10G PHYs, SAS expanders — all powered and ready even in a half-empty box.

If you keep enterprise gear, set the power profile to “Performance per Watt (OS)” or equivalent in the BIOS/iDRAC, enable C-states explicitly, and consider running on a single PSU (or set the second to hot-spare mode, which Dell supports, so one PSU carries the load in its better efficiency region). But understand the ceiling: a well-tuned R720 might drop from 130W to 95W idle. A mini-PC starts at 8W. Tuning cannot fix architecture.

Package C-States: The Difference Between 40W and 15W

Modern x86 idle power lives and dies on package C-states. Core C-states (C1, C6) gate individual cores; that is table stakes and almost always works. The big wins come when the entire package — cores, caches, memory controller, uncore — powers down together into PC6, PC8, or PC10. A recent desktop or mobile-derived chip that reaches PC8/PC10 can idle the whole platform under 10W. The same chip stuck at PC2 might burn 25–40W doing literally nothing different from the software’s point of view.

Check what you are actually achieving with turbostat (package linux-cpupower or linux-tools on most distros):

1

turbostat --quiet --show Busy%,CPU%c1,CPU%c6,Pkg%pc2,Pkg%pc6,Pkg%pc8,Pk%pc10 --interval 5

On a healthy low-power host you want to see Pkg%pc6 or deeper at 60–90% while idle. If Pk%pc10 (yes, turbostat truncates the column name) shows 0.0 and everything piles up in PC2, something is holding the package awake. powertop’s “Idle stats” tab shows the same data interactively, and cpupower idle-info lists which states the kernel even knows about.

Here is the critical, under-appreciated rule: the package can only sleep as deeply as its least cooperative device allows. Package C-states require every PCIe link to be in a low-power ASPM state, every core idle, and DMA quiet. One single device that keeps its link in L0 — a USB dongle without autosuspend, a NIC whose driver disables ASPM, a SAS HBA that never sleeps, a GPU with no runtime PM — caps the entire package at PC2/PC3. This is why two seemingly identical builds can idle 20W apart: one has a Realtek NIC silently vetoing PC8 for the whole machine.

Practical debugging order: run powertop, check the Tunables tab for devices in “Bad” state, unplug USB devices one at a time, and watch turbostat after each change. It is tedious and absolutely worth it.

ASPM: The Highest-Leverage Setting You Have Never Checked

PCIe Active State Power Management lets idle PCIe links drop from L0 (full power) into L0s/L1 (and L1.1/L1.2 substates). Without it, deep package C-states are unreachable. Check your current state:

1
2
3
4

# Global policy
cat /sys/module/pcie_aspm/parameters/policy
# Per-device: look for "LnkCtl: ASPM Disabled" vs "ASPM L1 Enabled"
lspci -vvv | grep -E 'ASPM|^[0-9a-f]'

For each device, LnkCap tells you what the hardware claims to support and LnkCtl tells you what is actually enabled. The aggressive policy is:

1

echo powersupersave > /sys/module/pcie_aspm/parameters/policy

or persistently via kernel cmdline: pcie_aspm.policy=powersupersave. If your BIOS did not whitelist ASPM (/sys/module/pcie_aspm/parameters/policy shows only default, links stuck disabled), the nuclear option is pcie_aspm=force on the kernel command line — with the explicit warning that you are overriding the firmware’s judgment, and some devices will misbehave.

And misbehave they do. The well-known offenders:

• Realtek RTL8125 2.5GbE (everywhere on cheap mini-PC and ITX boards): early silicon revisions had link stability problems with ASPM at 2.5GbE, so the r8169 driver disables ASPM broadly — including on later, fixed revisions. The result is a NIC that single-handedly blocks PC6+. You can re-enable it per-device (echo 1 > /sys/bus/pci/devices/0000:02:00.0/link/l1_aspm on recent kernels) and many people run this stably for 10–20W savings, but the documented failure modes are real: link flaps, throughput collapse, or the NIC disappearing from the PCIe bus entirely until a cold boot. Some boards even drop the NIC at boot if ASPM L1 is forced in BIOS.
• Aquantia/Marvell AQC107 10GbE: long history of ASPM-related instability; most guides recommend exempting it.
• LSI/Broadcom SAS HBAs: typically no ASPM support at all. If your NAS has one, deep package states are off the table for that box — factor it into your architecture rather than fighting it.

The honest procedure: enable ASPM, transfer large files over the affected NIC for an hour, watch dmesg for PCIe AER errors and link resets, and keep a way to get back into the box that does not depend on that NIC. If it is stable, you just bought yourself one or two package C-state levels. If not, exempt the device and accept the floor it imposes — or replace it with an Intel i210/i226 that behaves.

powertop –auto-tune, and Making It Survive Reboots

powertop is both a measurement tool and a tuning tool. The Tunables tab lists every runtime power knob — USB autosuspend, SATA link power management, PCIe runtime PM, audio codec power save — marked “Good” or “Bad.” Running:

1

powertop --auto-tune

flips everything to “Good.” On a headless server this is almost always safe and frequently worth 5–15W. The two caveats: USB autosuspend can make keyboards/mice/UPS data cables flaky (exempt them via udev if needed), and on desktops with audio you may hear pops from codec power-down.

Auto-tune does not persist. The standard fix is a oneshot systemd unit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# /etc/systemd/system/powertop.service
[Unit]
Description=PowerTOP auto-tune

[Service]
Type=oneshot
ExecStart=/usr/sbin/powertop --auto-tune

[Install]
WantedBy=multi-user.target

systemctl daemon-reload && systemctl enable --now powertop.service. While you are at it, set SATA link power management explicitly — med_power_with_dipm is the sane modern default (it is what Intel ships on laptops; avoid the older min_power on questionable drives):

1
2
3

for h in /sys/class/scsi_host/host*/link_power_management_policy; do
  echo med_power_with_dipm > "$h"
done

BIOS settings that actually matter, in rough order of impact:

1. C-states: enabled, package C-state limit set to Auto (or the deepest offered), C1E enabled.
2. ASPM: enabled or “Auto,” plus “Native ASPM” so the OS controls it.
3. Power profile: anything other than “Maximum Performance” — on Dell, “Performance per Watt (OS).”
4. Disable hardware you do not use: audio controller, serial ports, unused SATA controllers, RGB controllers.
5. ErP/EuP S5 mode if you do not need wake-on-LAN (it kills standby draw — but it also kills WoL, so choose deliberately).

Spinning Rust: hdparm, Spindown, and Why ZFS Refuses to Sleep

At 5–8W per spinning 3.5" drive, an 8-bay array burns 40–64W around the clock just keeping platters at 7200 RPM. Spun down, the same drives draw under 1W each. The tooling is hdparm:

1
2
3
4

hdparm -B 127 /dev/sda     # APM: values 1-127 permit spindown; 128-254 don't; 255 disables APM
hdparm -S 242 /dev/sda     # Standby timer: 241-251 = N*30min, so 242 = 60 minutes
hdparm -y /dev/sda         # Spin down right now
hdparm -C /dev/sda         # Check state: active/idle vs standby

(The -S encoding is a historical mess: 1–240 are multiples of 5 seconds, 241–251 are multiples of 30 minutes. Pick from the second range for sane values.)

The trade-off is mechanical wear. Drives are rated for a finite number of start-stop cycles — commonly ~50,000 spin-ups, with head load/unload rated around 600,000 cycles on NAS drives. Watch smartctl -A /dev/sda attributes 4 (Start_Stop_Count) and 193 (Load_Cycle_Count). The arithmetic is forgiving at sensible timeouts: 6 cycles a day is ~2,200/year, a rounding error against the rating. The failure mode is a too-short timeout plus periodic access, producing a cycle every ten minutes — that genuinely eats drives, and an overly aggressive -B value (the infamous WD Green default) can rack up load cycles even without full spindown.

Then there is ZFS. ZFS pools resist spindown structurally: any dirty data forces transaction group commits every few seconds, atime=on turns reads into writes, and the surrounding ecosystem — smartd polling SMART every 30 minutes, monitoring exporters, zed — keeps touching the disks. You can fight it (set atime=off, move system datasets and logs off the pool, lengthen smartd intervals, isolate frequently-written datasets onto SSDs), and a genuinely cold archive pool can sleep. But a pool that hosts VM disks, containers, or anything with a database will never stay down, and a drive that spins up every 12 minutes is worse off than one that never sleeps. If you run TrueNAS SCALE, its spindown settings exist but inherit all of these caveats. My opinionated rule: spin down archive/backup pools with 60+ minute timeouts; leave hot pools spinning and save your watts elsewhere — or move the hot data to SSDs, which idle at 0.05–0.6W.

The Consolidation Math: One Good Node Beats Three Old Ones

Everything above is tuning. The biggest single lever is architectural: stop running three 60W computers where one 10W computer suffices.

Modern Intel N100 and i3-N305 mini-PCs measure 6–15W at the wall at idle — fanless N100 units land around 6–10W in published reviews, and well-configured headless boxes report even less. An N305 gives you 8 efficient cores, 32GB RAM support, and 2.5GbE; that is comfortably enough to run the DNS, reverse proxy, Home Assistant, monitoring stack, and a dozen containers that are currently smeared across your rack. I compared the current field in the mini-PC homelab comparison, and for the truly minimal cases — DNS resolver, a couple of sensors — a Raspberry Pi or competing SBC at 3–5W is enough.

Worked example. Take the rack from the diagram: R720 (130W) + Xeon E3 box (55W) + desktop NAS (45W) = 230W idle across three machines. Replace with one i3-N305 mini-PC (~10W) running everything as VMs and containers, plus a purpose-built efficient NAS (~30W with four drives that actually spin down at night): 40W total, 190W saved.

190W continuous = 1,664 kWh/year. That is $250/year at $0.15/kWh and $583/year at $0.35/kWh. The $300 mini-PC pays for itself in 7–14 months, and then keeps paying. There is no tuning intervention in this entire post that competes with that.

Virtualization is what makes consolidation practical: one Proxmox VE host running ten VMs idles at essentially the same wall power as the empty host, because idle VMs are just idle processes — the hardware C-state machinery neither knows nor cares about the hypervisor. Ten bare-metal boxes pay ten platform overheads (ten PSUs at terrible load points, ten chipsets, ten BMCs); one host pays one. The honest trade-off is blast radius: one host down means everything down. For a homelab, a second small node for the genuinely critical services (DNS, router-adjacent things) restores most of the resilience for 10 more watts.

Turn Things Off: Wake-on-LAN, rtcwake, and Scheduled Duty Cycles

Some machines do not need to exist 22 hours a day. The backup target that receives one nightly job, the Windows VM host you use on weekends, the test bench — these should sleep.

Wake-on-LAN first. Enable it and make it persist:

1

ethtool -s enp1s0 wol g        # enable magic-packet wake (until reboot)

1
2
3
4
5
6

# /etc/systemd/network/50-wol.link  — persistent
[Match]
MACAddress=aa:bb:cc:dd:ee:ff

[Link]
WakeOnLan=magic

Then from any always-on node: etherwake -i enp1s0 aa:bb:cc:dd:ee:ff (or wakeonlan). Note that WoL requires the NIC to stay in a low-power-but-listening state, costing 1–3W in S5 — and it conflicts with the ErP BIOS setting mentioned earlier.

For machines that should wake themselves on a schedule, rtcwake programs the RTC alarm:

1
2

# Power off now, wake at 02:00 tomorrow
rtcwake -m off -l -t "$(date -d 'tomorrow 02:00' +%s)"

Wire it into cron and the duty cycle runs itself:

1
2
3
4

# On the always-on node: wake the backup target before the job
0 2 * * * /usr/sbin/etherwake -i vmbr0 aa:bb:cc:dd:ee:ff
# On the backup target: power off after the backup window
30 4 * * * /usr/sbin/shutdown -h now

The math: a 60W backup node that runs 2 hours instead of 24 saves 1.32 kWh/day — 482 kWh/year, $72 at $0.15/kWh, $169 at $0.35/kWh. For one cron line on each side. The trade-offs are honest but small: boot wear is negligible on modern hardware, but you lose ad-hoc availability (mitigate with WoL from your phone) and you must make sure the box is not quietly hosting something stateful that resents power cuts.

Undervolting: Real, but Marginal at Idle

Undervolting reduces the voltage/frequency curve so the chip does the same work on less power. On older Intel (6th–9th gen), intel-undervolt can shave meaningful load power; Intel locked the interface on most newer platforms after the Plundervolt vulnerability, so on 10th-gen+ you are limited to whatever the BIOS exposes. On AMD, Curve Optimizer does the same job and remains available.

The catch for this post’s purposes: undervolting mostly helps load power. At idle, a chip in PC8 is barely using its voltage rails at all, so the savings are small — a few watts at best, sometimes nothing. Do it if your box also works hard (transcoding, builds), validate with hours of stress testing (an unstable undervolt crashes in ways that can corrupt in-flight writes), and treat it as the last 3% rather than a pillar of the strategy.

The Feedback Loop, and What It Is All Worth

None of this works open-loop. The discipline is: measure at the wall, change exactly one thing, re-measure. A $15–25 metering smart plug (Tapo P110, Shelly Plug S) or a Kill A Watt is mandatory equipment; software estimates like RAPL miss PSU losses, drives, and fans, which is precisely where your problem lives. I went deep on metering options, per-outlet PDUs, and turning readings into dashboards in the homelab power cost measurement guide — the short version is that the cheap smart plug pays for itself with the first tuning session.

Keep a log: baseline, then each change and its delta. Typical session on a tunable machine: BIOS C-states/ASPM (−5 to −15W), powertop --auto-tune + SATA LPM (−5 to −10W), fixing the one device blocking deep package states (−5 to −20W), drive spindown on cold pools (−5W per sleeping drive). Typical session on an R720: less, which is the point of the consolidation section.

What the whole program is worth, at 300W → 120W (a realistic outcome of consolidation plus tuning, while keeping a real NAS and switch):

(300W × 8,760 h = 2,628 kWh/yr; 120W = 1,051 kWh/yr; the 180W delta = 1,577 kWh/yr. Multiply by your tariff.) A useful rule of thumb falls out of the same arithmetic: one continuous watt costs $1.31–$3.94 per year depending on your rate. Price every device on your rack in those terms and the purchasing decisions start making themselves.

Verdict

The 300W idle homelab is not a law of nature; it is the default outcome of running datacenter hand-me-downs with datacenter firmware defaults. The fix has a clear hierarchy. Consolidation is worth more than all tuning combined: replacing old Xeon boxes with one modern mini-PC node plus an efficient NAS routinely cuts idle draw by 150–200W, and the hardware pays for itself within a year at almost any electricity price. Scheduled shutdown of duty-cycle machines is second — free, scriptable, and worth $70–170/year per 60W node. Tuning is third: C-states, ASPM, and powertop together typically recover 15–40W per machine, with the single biggest wins coming from finding the one device (usually a Realtek NIC, a USB gadget, or an HBA) that is vetoing deep package sleep for the whole box.

Be honest about the limits. ZFS pools that host live services will not spin down, and forcing them is worse than leaving them alone. ASPM on the wrong Realtek or Aquantia silicon will cost you a NIC at 2 a.m. Enterprise gear has a tuning floor you cannot break through. And none of it matters if you do not measure: buy the metering plug, establish the baseline, change one thing at a time, and let the wall meter — not the forum post — tell you what worked.

Sources

• Powertop — ArchWiki
• 80 Plus — Wikipedia
• Improve idle power consumption — Proxmox Support Forum
• Improving power efficiency and configuring ASPM — Level1Techs Forums
• Enabling ASPM on a Realtek RTL8125B 2.5GbE NIC in Proxmox/Linux — Zero Zero Lab
• ASPM disabled on Realtek NIC prevents deep C-states — Ubuntu Launchpad Bug #2085398
• Aquantia AQC107 NIC issues — Netgate Forum
• MINIX Z100-0dB fanless N100 mini PC review (power measurements) — CNX Software
• Fanless Intel N100 Firewall and Virtualization Appliance Review — ServeTheHome
• Low Power Server with Powertop & Proxmox — Virtualization Howto
• turbostat man page — Ubuntu Manpages
• Dell R720 idle power discussion — Hacker News
• Electricity Prices by State — Electric Choice
• What German households pay for electricity — Clean Energy Wire