I have a Threadripper workstation with two RTX A6000s in my home lab — a machine I'm proud of and slightly afraid of, wattage-wise. A few weeks ago I noticed warm air coming from it while it was supposedly doing nothing, and went down a rabbit hole that ended with a number I didn't believe: my "suspended" machine was drawing 179.8 watts.
Sleeping. One hundred and eighty watts.
Here's the whole story, with every command — because the odds are decent your Linux machine is doing the same thing, and checking takes sixty seconds.
The setup: doing everything right (I thought)
I did the responsible things first, and they were all real improvements:
- An idle watchdog — a 40-line bash script on a systemd timer that suspends the machine after 30 minutes with no SSH sessions, no GPU work, and no load.
- Wake-on-LAN, so a magic packet from my Mac wakes it in ~10 seconds. A sleeping server you can't wake remotely is a server you'll leave running forever.
- GPU runtime power management, CPU energy-preference tuning, the works.
The machine dutifully suspended itself every night. The logs said suspend entry. The fans quieted. I told people my lab slept at near-zero watts. I had verified everything — except the one thing that mattered.
The instrument arrives
I bought a ~$15 energy-monitoring smart plug to get the real number. First reading,
machine suspended: 179.8 W. My machine idles awake at a measured ~123 W.
Suspended, it drew more than sitting at an idle desktop.
The explanation lives in one file:
$ cat /sys/power/mem_sleep
[s2idle] deep
Linux has more than one kind of "suspend." s2idle is a software-only doze: the
kernel parks itself but the platform — fans, VRMs, devices — stays powered. deep
is classic S3: RAM in self-refresh, nearly everything else off. The brackets show
which one systemctl suspend actually uses. Mine said [s2idle] — and on my
platform, s2idle quiesces almost nothing. Worse than nothing, in my case: with the OS
parked, the power-management daemons that normally keep idle draw low stop running, while the hardware keeps burning.
If your machine only shows [s2idle] with no deep option at all, keep reading —
that was me too.
The fix was one BIOS bit
My board (an ASUS WRX90 workstation board) shipped with S3 sleep disabled in
firmware: Advanced → APM Configuration → S3 mode: [Disabled]. The kernel can't offer what the firmware hides. I enabled it, rebooted, and:
$ cat /sys/power/mem_sleep
s2idle [deep]
The kernel now defaulted to real S3 on its own. Next suspend, the meter read:
17 watts.
Same machine, same suspend command, same logs saying "suspended." 179.8 W → 17 W, from one firmware toggle. Wake-on-LAN still works (it's the NIC's oldest trick — S3 predates it by nothing). Resume takes a few seconds longer than s2idle. The GPUs came back clean.
The remaining 17 W is mostly my board's BMC — a small always-on management computer that gives me remote console and power control. That's a tax I pay willingly; a consumer board would sleep closer to 5 W.
Check your machine in 60 seconds
# 1. Which sleep does your machine actually use?
cat /sys/power/mem_sleep
# [s2idle] alone = you may have the same problem. [deep] = you're likely fine.
# 2. If deep is listed but not default, try it:
echo deep | sudo tee /sys/power/mem_sleep
sudo systemctl suspend
# (make it permanent with mem_sleep_default=deep on the kernel command line)
# 3. If deep isn't offered at all: check your BIOS for an S3 / ACPI sleep setting.
# Mine was under Advanced -> APM. Many boards ship with it disabled.
# 4. Trust no log — measure at the wall. Any energy-monitoring smart plug works.
# "Suspended" should read single-digits to ~20 W. If it reads like an idle
# desktop, your sleep is fake.
Caveats, honestly: S3 support on modern platforms is uneven — some laptops and boards dropped it entirely (that's a Microsoft/vendor "Modern Standby" story for another day), and resume bugs with GPUs do exist. Test a full suspend/wake cycle before trusting it unattended. My rollback plan was a smart plug that can hard-cycle the machine and a BIOS set to boot on AC restore — belt and suspenders, both $15-class fixes.
What it adds up to
My machine sleeps ~20 hours a day. The difference between fake and real sleep is
~163 W × 20 h ≈ 3.3 kWh every day — roughly 1,200 kWh a year, the annual output
of a solar panel or two, or about $150–180 at US rates, for one machine. Multiply by
every homelab, workstation, and "suspended" desktop out there and the number stops being cute.
The meter gets the last word. Yesterday — a full day of this machine existing, waking
when I needed it, sleeping when I didn't — its total consumption was 0.38 kWh:
an average of 17 W across nearly 23 hours, for a dual-GPU Threadripper workstation.
Under the old fake sleep, the same day would have cost over 4 kWh. That's the whole argument, in one line of a smart-plug app.
Three lessons I'm keeping:
- Logs describe intent; meters describe reality. Every log on my system said "suspended." Only the wall socket told the truth.
- Verify the claim, not the ceremony. I had tested that suspend happened — never what it achieved. Those are different tests.
- The fix is often absurdly small once you can see the problem. Weeks of automation work saved less than one BIOS bit. The automation still matters — it's what makes the 17 W state the default instead of a good intention — but the measurement is what made it real.
I run a small AI infrastructure lab and consultancy (Syntillation) focused on private, local-first AI systems, built on a principle this project made concrete: whatever I build — AI or not — should run with the smallest eco footprint that does the job, and that footprint should be measured, not assumed. A dual-GPU AI workstation that costs
0.38 kWh a day is proof the two goals aren't in tension. If you're doing the "how much does my hardware actually cost to run" audit on your own fleet, the answer starts with a $15 plug.
Top comments (0)