[RESPONDED] Bad battery life - high power draw at idle and light use (Framework 13 Ryzen)

Framework Laptop 13
1

@Matt_Hartley @Mario_Limonciello Are there concrete plans to address the high battery drain on Framework 13 Ryzen, through software and/or BIOS updates?

As is, the laptop is pretty useless for field work during a typical work day.

Using BIOS 3.03, and Fedora 39 with kernel 6.6.14, I cannot get the idle power draw to be lower than around 7 to 8 watts (as reported by powertop), even after going through many of the guides and suggestions presented here.

This includes installing the updated power-profiles-daemon @Mario_Limonciello (for better integration with amd-pstate) and setting the power mode to “Power Saver”.
https://copr.fedorainfracloud.org/coprs/mariolimonciello/power-profiles-daemon/

I also attempted various configurations via RyzenAdj, to no avail:

Disabling a subset of the CPUs helps a bit, but that’s a rather extreme solution:
$ echo 0 | sudo tee /sys/devices/system/cpu/cpuX/online
(where X is 8 to 11).

With light web browsing it only lasts about 4 to 5 hours, which is non-competitive in 2024. Watching a 2 hour movie (x265) easily drains 50% of the battery (VLC with hardware accelerated decoding).

Lastly, there is also relatively high power draw during suspend (s2idle).

Are there plans to address this via improved BIOS, and/or better drivers in the linux kernel, and/or supporting software?

The current state of the laptop is very disappointing. I cannot honestly recommend this laptop to my friends or colleagues.

2 Likes
2

Appreciate your feedback, however, this right here feels very wrong. I use mine with fairly active browsing and text work, lasts longer than that.

I generally keep my brightness to a lower level and use power saver, latest PPD. Not experiencing this.

Now if you are watching video, yes, you will experience battery drain at a higher rate.

1 Like
3

@Matt_Hartley I appreciate that the software side of the Framework equation might still be a work in progress. Given that, could you provide specific details on:

  • are there plans to release an updated BIOS (3.04) ?
    • if so, what would be the ETA?
  • what has changed between kernel 6.6, 6.7 and 6.8 that would improve battery life?
    • for example, better support for the Ryzen 7640U platform, and/or amdgpu?
    • is Framework actively engaged in pushing improvements (directly or indirectly) to the kernel?
  • are there any updates in the supporting software stack, besides the improved power-profiles-daemon?

When choosing the Framework laptop I was aware that there would be rough edges on the software side for a few months. However, the bad battery life is really a hill that’s too steep to climb.

4
  1. Have you made sure you added rpmfusion.
  2. Add all the codecs available.
  3. Enable Hardware Acceleration in your browser…make sure it is working…
  4. What is your screen brightness set at. If it is 100% there is one of the biggest culprits.
  5. Do you have any processes in the background chewing on the cpu.
  6. Turn bluetooth off, unless you are using it.
  7. Try tweaking the wifi cinfiguration.
  8. If none of that works try TLP (read the configuration file and understand) turn off Turbo on AC and see if that helps…yes I know not recommended, but at this point you have nothing to lose.
  9. No BIOS update, no kernel improvements, no software updates are going to matter if you are running that screen at 100% and running bluetooth, that’s 2-3w right there.
1 Like
6

@nadb Yeah, bluetooth is off and screen brightness is pretty low. During idle tests there’s nothing running except Gnome Shell and two terminal windows, with one running powertop.

It’s a standard Fedora 39 install, with the updated PPD, and rpmfusion enabled. Firefox was configured to use hardware acceleration. Kernel params: amdgpu.sg_display=0 amdgpu.abmlevel=1

7

Just going over obvious things. DId you calibrate powertop?

8

Generally using “balanced” with the patched ppd should be sufficient.

This will conflict with PPD and Framework’s EC. I suggest not using it.

Make sure that you have checked what slots your cards are in against what Framework suggests.

I have a plan to link ABM level 3 with PPD balanced mode, and level 4 with PPD power saver. This will help runtime consumption for the display.

9

As display panel is a giant consumer of battery, I think it would be useful to quantify what a lower level is to make it easier to compare values. This will tell you what brightness you have programmed to the panel (NOTE: this isn’t the value of “nits”, it’s an opaque measurement of 0-255) :

cat /sys/class/backlight/amdgpu_bl1/brightness
10

Agreed. I generally run between 35 to 40 in my home office setting. Full brightness would be 255.

I’d say 60 and below is reasonable.

11

@Matt_Hartley @Mario_Limonciello Update. I re-installed Fedora 39 from scratch, along with the updated power-profiles-daemon from Mario Limonciello’s COPR repo. Running kernel 6.6.15-200.fc39.x86_64. The previous installation was an upgrade from F38 → F39, which may have caused problems. USB-A module is installed in port 2 and DP module in port 4; other ports have USB-C modules.

In power-saver mode, the idle draw is now around 4.5 watts. This is certainly better on paper, but that’s not the whole story.

In contrast, my old Dell XPS-13 (Broadwell i5-5200U) draws around 2 watts at idle, with similar screen brightness. Where on earth is the extra 2.5 watts going to on the Framework laptop? Isn’t the 7640U CPU meant to be significantly more efficient?

Additionally, the Framework laptop gets noticeably gets warm with light workloads. Running Gnome shell, with Firefox 122 (2 tabs open, one on this site and one on outlook). Looking at /proc/cpuinfo, the cpu MHz hovers around 1397.366 MHz on all threads, and only occasionally drops down to 400 MHz for maybe one or two threads.

In contrast, the old Dell XPS-13 is happy to stay at its low frequency range for longer on the same workload, or at least drop the frequency quicker.

It seems that on the Framework laptop the OS is willing to jump way too quickly to higher frequency, and/or it isn’t dropping the frequency quick enough. For the lack of a better description, the power save mode really isn’t a power save mode. The Boost mode on the 7640U CPU certainly needs to disabled in power save mode.

Jumping to higher frequency (say past the baseline clock) should only occur if there is a sustained high load for, say, at least 1 second. By “high load” I mean a proper computationally intensive task (such as matrix inversion or singular value decomposition on a large matrix). It is certainly not viewing mostly static web pages.

Additional observations: suspend (suspend-to-idle, aka s2idle) kind of “works”, but it still draws way too much power for doing essentially nothing. It’s definitely not safe to have the laptop suspended over night.

What happened to deep suspend (suspend-to-RAM) ? s2idle is simply not fit for purpose.

Keyboard backlight. On the old Dell XPS-13, the keyboard backlight automatically goes off after a short period of inactivity. On the Framework, it always stays on, and can only be turned off via FN+space. Shouldn’t this be automatic as well? More specifically, it would be useful to have the keyboard backlight timeout as a setting in the BIOS, or at the very least have some knobs exposed so that it can be done at the OS level.

12

If you haven’t already, try looking some software that can tell you what is triggering a ton of interrupts for your machine. For example powertop has this in the overview page. You can compare this to your other laptop too to help understand what’s causing various wakeups at runtime and what can be done.

This is a very complicated topic that is not black and white (lot of nuance). There are lots of things that can be tuned such as the EPP bias (which happens when you go into powersave) or you can switch away from the CPU EPP algorithm into what’s called “guided” mode which you can dictate exactly what performance target you want to hit.

You can also cap min and max frequencies, even in EPP mode which might also get you what you want.

I won’t call out names but I’ve worked on laptops that the manufacturer decided to do S3 for Linux and Modern Standby for Windows. The power consumption was higher when S3 was in use. That manufacturer has since shifted to s2idle for Linux and Modern Standby for Windows. The numbers are nearly the same now (after Windows gets into the right state - ~10 minutes). You can look at a Sleep Study for Windows to see what it looks like compared to an s2idle report in Linux (which captures similar data).

1 Like
13

I suspect that the default WiFi card contributes the power drain issue.
The default is AMD RZ616 Wi-Fi 6E: Framework | AMD RZ616 Wi-Fi 6E

Various forum posts suggest that the Intel AX210 No vPro card is compatible with FW13 AMD and has lower power usage: Framework | Intel Wi-Fi 6E AX210 No vPro

This reddit post (dated ~6 Dec 2023) describes a very similar high battery drain at idle problem:
https://www.reddit.com/r/framework/comments/18c8yk7/high_battery_drain_when_sleeping_amd_13/

The above post has been updated with the following details:

UPDATE:

I’ve done some testing. Physically removing the wifi card, sleep works as expected and has low battery drain.

So something about wifi/bluetooth is waking it up.

Setting rtc_cmos.use_acpi_alarm=1 doesn’t do anything.

The only thing that’s worked is setting acpi.ec_no_wakeup=1 in the kernel parameters, and I’ve had ~5% battery loss in 6 hours. It’s a little more annoying waking it up from sleep as opening the lid doesn’t trigger the wake up, so it’s a bit of a workaround but it does the job.

14

It’s best to gather hard data evidence. Run an s2idle report with the card in the system for 4 hours, remove the card and repeat.

The reports will capture how much battery is lost (and estimate your drain rate).

2 Likes
15

This might be a bit off-topic, but how exactly would you do that, @Mario_Limonciello? Assuming we are in the amd_pstate=active mode, using PPD, and while not interfering with the FW EC? I was able to do this with ryzenadj, but I understand you recommend against it?

16

ryzenadj doesn’t adjust anything with EPP
It adjusts essentially CPU coefficients that influence things like TDP.

You can just use the kernel sysfs interface to write values for min/max frequency for each CPU you want to limit.

17

Do you mean something like this?

echo MIN_FREQ_KHZ > /sys/devices/system/cpu/cpuX/cpufreq/scaling_min_freq
echo MAX_FREQ_KHZ > /sys/devices/system/cpu/cpuX/cpufreq/scaling_max_freq

How would that handle boost, and how well does this work with the amd_pstate=active profile? I couldn’t tell that from the documentation page.

Ultimately, the goal is to force lower TDP. I’m still unclear how to do this effectively and safely on FW13 AMD. ryzenadj seemed to work, but I can’t tell if it did, in fact, also mess something up at the same time.

18

Yeah

It works fine with the latest stable kernels. There was a bug with it that I just fixed 3 weeks ago: cpufreq/amd-pstate: Fix setting scaling max/min freq values · torvalds/linux@22fb4f0 · GitHub

Use the ACPI platform profile sysfs file to do it (this is also what PPD slider does). In the low power position it will tune the CPU coefficients in the EC.

If you’re not happy with the CPU coefficients that are changed you are best off rebuilding the EC with the values you want for the particular situation.

1 Like
19

Interestingly, setting scaling_max_freq to 400000 (the same value as cpuinfo_min_freq) for all cores on the 7840U

echo "400000" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq

resulted in a significantly higher power draw while executing a Unity-based benchmark: almost 40W battery discharge rate vs. just over 20W with the default settings, as reported by powertop. The benchmark’s frame rate was slightly higher too, even though CPU frequencies on all cores reportedly remained under 600 MHz (they did exceed 500 MHz, however, as the benchmark ramped up). The platform profile was set by PPD to low-power.

So, either the reported frequency values are wrong, or the reduced efficiency leads to spending much more energy on trying to get to the performance level the benchmark forces.

With the low-power profile I’m still getting the power draw over 20W. What I would like to do is to be able to cap the power draw under 10-15W, at the expense of the performance, at least while running certain applications (some Unity-based games, for example, that seem to be unreasonably CPU- and power-hungry, and work fine throttled down).

I am not clear if the only way to accomplish that cleanly would be to rebuild the EC. If it is, unfortunately, I wouldn’t know how to go about doing that.

20

~5 month update. The AMD Ryzen 7640 laptop is now in a notably better state, with lower battery drain.

It appears that the recent BIOS update (3.05) and the newer OS-level software on the Linux side (Fedora 40 and Ubuntu 24.04) have mostly caught up with the hardware. Using kernel 6.8.10 and power-profiles-daemon 0.21-2.

Many thanks to the Framework team (including @Matt_Hartley), AMD folks (including @Mario_Limonciello), as well as other reporters and open-source volunteers in improving the situation.

The one thing that is still an issue (though beyond the control of Framework) is fractional scaling support in Gnome. The implementation in both Gnome 45 and 46 still draws way too much power. KDE Plasma seems to be in a better position here.

As a workaround, I’ve set the display resolution to 1680x1050. The aspect is 16:10 rather than 3:2, but still better than 16:9.

I’ve also found that manually setting the max power state of the SSD can help with reducing power consumption:

nvme set-feature /dev/nvme0 --feature-id=2 --value=2

The above can be placed in /etc/rc.d/rc.local (created as root to avoid issues with security policies). Under Fedora 40 rc.local is executed at boot via the rc-local systemd service.

To see available power states and their power use: smartctl -a /dev/nvme0
To see current power state: nvme get-feature /dev/nvme0 -f 2 -H

PS. for more power efficient video playback (hardware decoding), install the Mesa multimedia packages from rpm-fusion and use the VLC flatpak obtained from Flathub instead of the default Fedora repositories.

Once the appropriate Mesa drivers are installed, set the hardware-accelerated decoding to “VA-API” in the flatpak version of VLC.

Related info: Hardware video acceleration - ArchWiki

1 Like
22

Interesting point with the nvme. Have you done any benchmarking? Even empirical measurements? How many power states does your nvme offer? What does it start up in? Which one do you pick?

I’m wondering if this is something else we should tune in PPD by default.