Is Framework 13 AMD s2idle (modern standby) efficient enough?

There are other topics dedicated to troubleshooting issues with suspend, however, I believe, in my case, it works as intended, but… I am not sure it is good enough.

I will be focusing on Linux since this is what I know, but, based on what I read in other topics, the situation on Windows is similar.

Here is a specific data point:

  • Last night, my laptop was suspended for 39930 seconds (roughly, 11 hours and 5 minutes).
  • Of those, it spent 39923 in hardware sleep state, that is, almost the entire time (the difference is 7 seconds, which, by the way, is pretty large – normally it is more like 2 seconds, and I am not sure what was different this time).
  • The battery went down from 70% (2744 mAh) to 62% (2460 mAh).

This gives us a rate of 0.65% (25.6 mAh) per hour of sleep. Elsewhere on the forum, I saw people report the rate of around 1% per hour on Windows, so, comparable.

Now, here is the question that I keep asking myself: is this good, merely acceptable, or bad? E.g. this means that the battery will be essentially empty after 6 days of sleep. My personal feeling is that this is sort of acceptable, but I would definitely wish for much more.

Microsoft seems to agree! Their Modern Standby Duration Test says:

Systems that support Connected Standby are recommended to drain less than 5% of system battery capacity over an 16 hour idle period

If I scale the result of my experiment, I am getting the drain of 10.4% over 16 hours – more than twice as much as recommended and it is not even Connected Standby as in their test.

So, where do we go from here? @Mario_Limonciello’s amd_s2idle.py script doesn’t find any issues with my system and, given that it spends pretty much the entire time in the deepest hardware sleep, I suspect there is nothing I can really do to improve the situation on my own, at least not on the software side.

Should I be looking for more power efficient hardware parts? Is there anything that Framework can do to reduce the drain? Can AMD help?

3 Likes

It’s certainly not Macbook level of efficiency. However, it’s comparable to my other Intel Chromebooks which are using probably the most battery-consumption optimized Linux laptop platform.

1 Like

Great question. I’m really curious about what’s exactly happening during s2idle, and whether there’s any potential for improving efficiency.

As a point of reference, my other Linux laptop draws a mere 0.17W in S3, which is 0.3% per hour.

On the AMD Framework 13, it looks like s2idle baseline draw is 0.23W with another 0.05W - 0.9W for RAM, depending on what’s installed. That’s 0.5% - 1.9% per hour.

So yes, selecting different RAM is one way for users to improve suspend efficiency, but it’s difficult to know what to expect before purchasing parts. These consumption specs aren’t advertised.

But I don’t know what accounts for the other 0.23W not attributed to RAM. What hardware remains powered on? How much does the AMD CPU need in its standby state? Is it comparable to a microcontroller on standby, which might be on the order of 1mW?

I’d like to believe that s2idle could approach S3 efficiency if everything has a proper low power state. Is this a realistic expectation? If not, then it’s very unfortunate that we lost S3 on modern hardware.

I would agree, however if that connected standby times of Microsoft are to be believed, then S0 connected standby is doing just as well as S3 on your other Linux laptop.

I was one of those people who was sticking on team Intel because of the better Thunderbolt and port selection, but it is hard to argue with the sheer efficiency and performance metrics of the AMD mainboards. I mean a suspend time of 6 days is something I’ve never seen on any of my previous laptops. (All Intel based)

The bit that causes Windows to prefer S0ix over S3, even if both are declared is literally defined as “S0ix is more efficient than S3” in the ACPI standard.
If anybody can prove that all modern x86 processors lie when setting this bit (the manufacturers setting this bit in BIOS), this would be news.
My expectation would be that the CPU+RAM can easily hit the same power consumption or less than S3. And its all about the other components on the board and how often they wake up.
I am just unclear how much of this is regulated by the OS, how much is firmware and how much is hardware design.
For example Windows leaves BT connected while sleeping. Also means the WiFi card is still powered and not disconnected. But it’s completely possible that this takes up negligible amounts of power.

With Windows for example my 12th gen wakes up like once an hour to waste 30secs somehow on the SSD (according to internal logging, its still considered “sleep”). This makes sleep power consumption under Windows very variable. I need like 4h+ to get to more stable results because the wakeups get a little rarer.

I’d absolutely love a blog post from framework about where the power is going, which has potential for optimization and which is just a tradeoff for functionality or modularity…

Since I see 280mW - 340 mW with Windows on my 12th gen, which includes the wakeups, I am convinced Windows could get that number down if it wanted and would cease the stupid online checks. And differences between 1x 16 GiB SoDIMM vs 2x or 2x 8GiB modules were below the variance I cannot eliminate with Windows.

As I understand, the current Linux distros are not setup for modern standby. Meaning the waking the CPU up on HW events, handling it and simply going back to sleep unnoticed. Any event that remains enabled will wake the whole PC just as a keyboard press would. So Linux distros currently are incapable of that background work while sleeping. But they probably also have more problems putting all hardware to sleep.

1 Like