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

Framework Laptop 13
1

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?

4 Likes
2

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
3

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.

4

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)

5

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.

2 Likes
6

I get similar numbers to you when running the s2idle test, however the laptop only sleeps for two days before dying.

If it could last a week I’d be thrilled.

I’m not sure how well windows sleeps as I don’t have a license. But it does seem like something wakes up system periodically given all three platforms have reports of hot dead laptops when waking from suspend

7

Windows is what is staging activity during S0. The hardware doesn’t have some task it has to run out of instinct. Linux does not do this at all, and thus no hardware is doing things it shouldn’t during sleep. However don’t think this is because Linux is just better here. Linux is just MUCH slower at adopting new technologies and system specific features.

On Windows you can force S3, as the hardware supports it. This ensures that the machine simply sleeps when it is told to, however, the laptop will also sleep all the way to a drained battery.

I prefer S0 network disconnected. It will suspend with no network, and then after using 5% of the battery hibernate automatically. There are massive improvements that can be added to the Framework driver stacks for Windows that would greatly improve S0 performance. There is no way MS could report numbers like they did without this optimization. Lenovo, Dell, and HP (for example) all exhibit this kind of efficiency when suspended.

1 Like
8

I did not. I even referenced why. The kernel seems 100% capable of this. It is how Android works. It’s PID0 that is lacking support. Because it would need to put itself into modern standby mode. And on every wake check, whether this is a user wake or just some hardware event to react to.

Windows does some background work, yes. Although it seems to disable that pretty much on battery. Most of what is done is due to hardware.
Like newly plugged in devices, changed network connectivity, changed power state (AC power available or not), monitoring battery so the system can go to hibernation and will not deep-discharge the battery…
With Windows’ logging I have narrowed down the rogue interrupts in the middle to the NVMe. And the Windows network connectivity checks seem to happen as a result, as its already awake anyway. I have not managed to find out what the reason for this interrupt is and if the SSD is going rogue and sending an interrupt it should not or if Windows has asked it to do sth.

You can force S3, IF the hardware supports it. For my FW13 12th, the BIOS declares support, even though Intel does not support it for the CPU and the hardware and firmware was never designed for it. For example various components stay powered (like WiFi card). Because for modern standby systems there is no need to have the BIOS cut power. Because the OS can manage it. On the other hand, I believe the touchpad, keyboard, fingerprint failed to work as wake source, because some parts of it were obviously unpowered in the incomplete S3 mode it has.
Also, Microsoft says, they configure settings during setup depending on hardware support. And just the registry hack will not change those settings. So Windows might have various, hidden options misconfigured if you do that. But without documentation hard to know. My system freaked a bit after reverting to modern sleep. I had to forcibly reinstall WiFi drivers to fix that again. So I think this might also cause even more issues.

This could be an example of Windows simply not requesting this wake and not changing this option based on the registry hack, but simply as an option of the power profile that needs to be changed manually (normally done during install).
Or it could also be a BIOS failure, because it was never tested for S3, because it’s not officially supported. Because for S3, I believe its the same ACPI features for wake alarms by time that is supposed to wake the system on reaching a pre-configured battery charge level. While modern standby does not use it and monitors the battery much more granularly. Or in case of Linux, does not, because the distro cannot handle waking the kernel without waking user space.

9

It is worth saying that this script - which could be more informatively named - is obtainable here.

2 Likes