Will power drain during sleep ever be patched?

I believe in the Framework’s mission but this ginormous power drain during suspend/sleep is a productivity turn off.

In my testing using s2idle scripts and manually, I found that there’s a consistent power draw of 9000µAh every minute the machine is suspended. It’s much worse on Windows and stock Linux kernels (Ubuntu 24.04 and other distros).

However, using the latest non-default 6.10 kernel (openSUSE), it’s slightly better at around 4000µAh. And if you use powertop --auto-tune, it’s around ~3000µAh. I am using 96GB of RAM but I have seen people reporting about the issue with 16 or 32GB as well.

There are other AMD machines on the market where this is not an issue e.g. Thinkpads etc.

After 24 hours in sleep, the machine has 29% of battery remaining down from a 79% charge. It’s significantly better than what I get in Windows, where the machine simply dies.

I feel like it’ll never be able to replace Macbook Pro M3 if you’re on the go, let alone my M1 in terms of performance per watt but then again it’s not an apple to apple comparison (pun intended) when it comes to modularity & repairability.

So my question is, will the sleep power drain issue ever be fixed in firmware/hardware?

1 Like

i’m on win 11 and I set it so when the lid closes the laptop hibernates and this has pretty much eradicated the sleep drain issue it just takes roughly 10-15 seconds to boot up once opened.

2 Likes

µAh every minute is quite possibly the most cursed unit I have ever seen used to measure power drain, especially since the same rate of energy discharge will result in different µAh/min values depending on how fully charged the battery is when you take the measurement.

A much more normal unit would be mW, which assuming you have the 55 Wh battery and are making the measurements when the battery is 50% charged the conversion is 1 µAh/min = 0.924 mW.

So they’re pretty close, but most people don’t know that.

Out of curiosity, how are you arriving at those numbers? I doubt any software (at least not any software I’d trust to report accurate results) reports in that unit, but if you are converting to that: Why?

That is unlike anything I’ve seen from my Framework Laptop 16 (which I’d expect to have the same or higher drain than the AMD Framework Laptop 13). I typically get around 20% drain in 24 hours on Linux and 6% on Windows (with the default behavior of Windows entering hibernate if the battery drains more than 5% in the first 12 hours after entering sleep).

To me that sounds like something may be wrong.

3 Likes

The solution to this type of problem is normally a software fix.
For sleep, in general, the only thing that needs power is the RAM and whatever device senses the power on from sleep (e.g. power button), everything else can be powered off. The common reason for the power drain during sleep is it fails to power off one or more of the devices during sleep, or the laptop has woken up without one intending it to.
The problem is then identifying which device is causing the problem?

My FW16 Linux Ubuntu 24.04 with 64GB RAM uses 2-3W when in suspend (Measured on the AC side of the FW16 power brick.). More RAM will use more power during suspend.
FW16 85Wh battery, might last for 85 / 3 = 28 Hours. 85 / 2 = 42 Hours.
FW13 55Wh battery, might last 55 / 3 = 18 Hours. 55 / 2 = 27 Hours.
The AC power brick at these low Watt power levels is probably not very efficient, so the amount of power needed from the battery while asleep is likely to be less than the 2-3 I measured.
I have not actually tested any of this. I.e. put laptop into suspend and waited until the fade in/fade out power LED goes out, indicating a power fail.

1 Like

Right. Definitely not the best way to measure. An energy unit would be better. The values came directly from /sys/class/power_supply/BAT1/charge_now. I think the amd_s2idle.py script uses it as well.

On Windows, I have default hibernate disabled cause I don’t want it to pile up the TBWs with ~40GBs of C:\hiberfile.sys every time the machine goes into extended sleep since I have 96GBs of RAM, for my workload.

It’s a brand new Framework 13" AMD 7840U. So I just did a couple of battery cycles and loaded the Optimal Defaults in BIOS. Now the sleep consumption is around 2% per hour under Linux kernel v6.10. Still far behind what an M1 can achieve but slightly comparable to yours.

I’ll try pulling out one 48GB RAM module and do the testing in degraded mode to see if the sleep drainage falls to ~1% or so, which would be something I can definitely live with!

Since I managed to get hibernate working rock solid, I’ve opted for a suspend then hibernate after a period to sustain battery life. It’s a work around I know but works for me.

IMO s2idle just seems a bit crap, bring back the old S3(deep sleep) days!

2 Likes

I have a Framework 13 AMD, I happen to be running Arch Linux, but I was in this boat of losing almost 50% of battery overnight while “suspended”, until I fixed a couple of things I had customized, and now it loses less than 10% overnight. Try @Mario_Limonciello’s script which helps diagnose whatever may be preventing s2idle sleep from working properly under linux (for AMD models): https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py

… although I’m not sure why Windows has such bad sleep power consumption for you as well … be sure to check your add-in cards, some use more idle power in some positions. For a test to rule-out the possibility you can just remove them all overnight.

Already ran and reports no issues; please see above posts! Also, I got it down to 2% drain per hour of sleep with 96GB of RAM.

Just tried that as well and as expected it indeed 1% drain per hour of sleep.
Test parameters:

Framework 13 AMD 7840U

  • Battery: 61Wh
  • RAM: 48GB single module (subpar)
  • OS: openSUSE Tumbleweed
  • Kernel: 6.10 stable

Still not the best if you have more than 16GB of RAM but okay. Maybe it’s better to go with shut down on lid closure.

S3 is probably never coming back (there used to be ways to enable it on earlier AMD machines via UMAF but not anymore I guess).

I would say you should sooner do suspend then hibernate. This is “more” like how Windows handles things then too.

1 Like

I had an issue with power drain on both Windows and Linux, the culprit was the HDMI expansion card. Not surprising since mine it’s the original HDMI card with the power consumption issues