[TRACKING] Linux battery life tuning

Has anyone looked into battery life tuning for the AMD versions, yet?
I upgraded from an i5-1135G7 mainboard to a Ryzen 5 7640U, mostly for the battery life.

However, at least at the moment, it’s significantly worse.
I have only changed mainboard and RAM; all other components stayed the same.

I’m looking at an idle power draw of 5-6W, in contrast to 3-4W with the Intel mainboard.
Just web browsing is around 9-11W; previously around 6-7W.
Video playback is the worst, however. It’s using anywhere between 11-13W (Full HD, 30% brightness), which also routinely makes the fan spin up. With my Intel board, I looked at 7-8ish Watts for video playback.
This makes a full battery drain in 4-5 hours, which is pretty short.

As per recommendation, I am using power-profiles-daemon instead of TLP.
All of this is with it set to Power Save.

3 Likes

i bought a new ryzen 5 DIY laptop. i’m also hitting about 6W on idle (like, no programs open, just on the desktop). hitting about 10-12W for web browsing, and 18W for video playback (40% brightness).

using PPD on Power Save, fedora 39, 3.03 bios.

Matt said not to use TLP on AMD, but I’m getting such poor battery performance on ppd that I think i’m going to try TLP and maybe autocpufreq.

But you are on a recent kernel and stuff right?

I’m on Kernel 6.5.5, but have also tried 6.6.0rc, which makes no difference.
cpupower frequency-info tells me I’m on amd-pstate-epp, which, to my knowledge, is the correct driver.

1 Like

Very similar for me on kernel 6.5.9-arch2-1. A bit lower on video playback in firefox, 14-16W. PPD or TLP does not make a whole lot of difference, but I decided on PPD as recommended. GPU and CPU seem to clock down correctly, removing all extension cards does not change the power use. My installation is a swaywm desktop with pretty minimal background tasks running.
Maybe SSDs not entering power save modes could be a factor? I do not know how to check that. I’m currently using a WD SN850X.

Edit:
Found lspci -vv | grep 'ASPM.*abled;'in the Arch wiki.

echo powersupersave > /sys/module/pcie_aspm/parameters/policy

turns some of the “Disabled” entries into “Enabled” and that seems to reduce power use a bit. This is not persistent between reboots and I do not know if it has negative implications.

I did a lot of testing over the last few days (TLP, auto-cpufreq, PPD, just Kernel) . Summing up i noticed a much higher battery drain of the AMD 7040 compared to my Core i7 (13 gen) but i managed to reduce the power consumption on battery significantly.

First of all beside of firmware problems (wifi needs > 60s to initialize) i noticed that the AMD wifi card uses a lot more energy (+0,5W in Idle and 1-2W under load) than my “old” Intel AX210. I removed the AMD wifi chip and replaced it with the AX210 on my AMD7040 mainboard with no issues so far and the benefit of battery saving.

My test setting was always: 1.) idle (20% Backlight; no running apps; after 2 mins); 2.) light browsing (Firefox on different websites); 3.) writing a text in Libreoffice; 4.) watching Youtube-Video (1080p; av1).
I’m using Manjaro Gnome with Kernel 6.6.0.

Here are my results:

  • just Kernel: 1.) 6-7W; 2.) 10-12W; 3.) 8-10W; 4.) 16-20W

  • PPD (power saver): a little bit worse than just Kernel, so i can’t understand the recommendation of that daemon?

  • auto-cpufreq alone(standard config): 1.) 5-6W; 2.) 8-11W; 3.) 7-9W 4.) 14-18W

  • TLP and auto-cpufreq in combination (all CPU optimizations must be commented in TLP!): 1.) 4-5W; 2.) 5-8W; 3.) 5-8W; 4.) 11-15W

I have the best results with TLP and auto-cpufreq in combination. After two days of heavy using my Framework with that setting i experienced no major issues so far. The only thing is a weird behavior after suspend that shows up occasionally. The cpu then tends to throttle under load. A reboot resolves that. One setting in TLP that reduces the power consumption above all was the powersupersave of pcie (ASPM).

As I’m writing this text in Firefox my power consumption is always between 5-6W which is really good…for now I’m satisfied.

8 Likes

I would try a TLP only as TLP and auto-cpufreq can at times conflict. Generally speaking simply disabling turbo on battery in TLP provides the most saviings. I am using a 12th gen Intel and regularly sitting under 5w. You should be seeing better with that new AMD CPU.

3 Likes

Interesting, I’ve seen your posts around @nadb in the past and have been impressed with your results. If you could, what’s your power usage while playing big_buck_bunny_1080p_h264.mov through e.g mpv? Just curious, no pressure at all :slight_smile:


PARTYYYYYYYYYTIMEEEEE.
I upgraded 2 days ago from Intel i7-1165G7 to AMD 7080U, here’s a detailed gist with issues/resolutions as well as my TLP config. @Matt_Hartley I know you’re swamped; the above info may help (it’s a bit messy though). I’ve condensed the key notable points from there below for this thread:

Key points

This is for my Fedora 38/SwayWM installation that I’ve kept since it’s my daily driver, and am holding off upgrading to the recommended Fedora 39 Beta.

Here are my current power consumption results:

  • Idle: ~3.6W
  • Big Buck Bunny 1080P VAAPI HW decode: ~6.2W (has gone down to ~5.9W)
  • Big Buck Bunny 1080P no HW decode: ~6.2W
  • Firefox YouTube 1080p: ~8.7W

5% brightness, Intel AX210, 2TB SK Hynix P31, 2x32GB G.Skill 5600MT/s RAM).

I’m using TLP 1.6.0 which is the earliest version that supports AMD Zen 2+ which I had to manually install (not in F38 DNF yet). Instructions in gist.

Freeworld drivers causing higher power usage on F38:

At least on my system, these drivers result in significantly higher power usage (about an extra 1-3W):

mesa-va-drivers-freeworld-23.1.9-1.fc38.x86_64 
mesa-vdpau-drivers-freeworld-23.1.9-1.fc38.x86_64

vs. these:

mesa-vdpau-drivers-23.1.9-1.fc38.x86_64
mesa-va-drivers-23.1.9-1.fc38.x86_64

Wi-Fi power management

With my Intel AX210:

  • TLP WIFI_PWR_ON_BAT=off: ~4.5W idle
  • TLP WIFI_PWR_ON_BAT=on: ~3.7W idle

Wayland Fractional Scaling

On SwayWM, Firefox YouTube 1080P:

  • No scaling: ~8.7W
  • 1.25x scaling: ~9.2W

Might be fixed with latest Fedora 39/Sway/wp-fractional-scale-v1, not tested.

Disabling btrfs discard=async

I added nodiscard to my /etc/fstab after I saw btrfs_discard_workfn in powertop cause 1W to a few W power spikes (and made sure fstrim.timer/fstrim.service was setup, should already be on Fedora).

power-profiles-daemon

I got significantly higher power consumption with PPD, and just saw this proposal today to replace PPD with tuned for Fedora 40.


Average power consumption vs. my 11th gen Intel seems much lower, so I’m content. Time to actually use this thing with the inevitable future optimizations! ! ! ! ! !! !!! !!! :smiley:
Edit: oh and noticeably faster. zoom zoom
Edit 2: oh yeah, sometime later I plan to undervolt, anyone successful there?
Edit 3: will update when I upgrade to F39 in a few weeks when the dust settles

6 Likes

The damn file was just taking forever to download…so I ran the 720p version through vimeo, in firefox. It was sitting at 9.32w. This is about what I expect for most video. Depending on the codec being used it will sit as low as 8.5w and up to about 11w. At 35% brightness, which is what I usually have it set to plugged in or not. For most of my daily usage it sits under 5w boosting over it while loading a new url, and quickly dropping back down to idle.

2 Likes

hey the download speed is really bad :confused: (like 100kb/s). would it be possible for you to upload it to a site with better download speeds? gdrive, mega, or pixeldrain (which is awesome) would probably be much faster.

1 Like

@nadb thanks, hmm yeah that’s about what I was getting on 11th gen with web videos playing in Firefox. I think Linux Firefox hardware acceleration power consumption can be improved lots since playing the file in mpv consumes much less (without buffering though). Lol just mirrored the file below :smiley:

@umbra Yes! Here’s the pixeldrain link (cool!).

Also tried posting a Google Drive link but my post wasn’t going through, I think it got blocked.

1 Like

I also upgraded from an intel 12th gen to the AMD framework, I found the majority of the power savings from switching away from TLP (to PPD) came from just this:

https://wiki.archlinux.org/title/Power_management#PCI_Runtime_Power_Management

namely a udev rules file with:

SUBSYSTEM=="pci", ATTR{power/control}="auto"
4 Likes

Just went down the TuneD rabbit hole and once again the same problem I have with PPD. They want to simplify and automate the stuff that I want direct control over. I don’t want on the fly adaptation to my usage at that specific moment. MIght it give me a slightly more responsive system…sure, but in the end when I am on battery i want it to run well, I am willing to take something of a performance hit. I am willing to manage my expectations around that performance hit while on battery. When plugged in I want max performance and I am willing to accept a certain level of noise, but once again I want to control that. In my years of playing with and working with linux I have found that TLP with Thermald gives me the performance, and battery life profile I want in a laptop. This happens with minimal manual intervention on my part and once set it is on auto-pilot, I don’t need to play around, I don’ t need to manually select profiles, and don’t need to hope that turbo is not constantly kicking in while on battery to “enhance” my experience.

This is the kind of under the hood change that can create all sorts of troubleshooting nightmares the second it runs into something that does not behave. PPD suffers from the same issue a lot of projects suffer from…not designed here…don’t want to use. Also I got sour on PPD from the start when they esentially bad mouthed other projects by suggesting they do “dangerous things”…yeah I do lots of “dangerous” things with my hardware, it’s linux…I have that choice, I research it and test it, and it is my choice.

In short do what works for you based on testing it for your use cases, and desires. That at least is why most of us who run linux are using it in the first place.

1 Like

I got excited to try, but realized I already have that set in TLP since it’s enabled by default in battery mode (via RUNTIME_PM_ON_BAT=auto):
https://linrunner.de/tlp/settings/runtimepm.html#runtime-pm-on-ac-bat

Was there a difference when setting the udev rule directly?
I have no negatives to report from that setting (which I also used on 11th gen Intel).


@nadb thanks for going down that rabbit hole, and that’s essentially how I operate as well. However, curiosity struck me (argh!) and apparently TuneD allows edit: will allow? custom profiles:

include a number of predefined profiles for common use cases…and it is possible to fully customize them

From: https://tuned-project.org/

And their currently in development documentation for Customizing TuneD profiles

So TuneD would essentially be TLP with the extra ability to create as many profiles instead of just 2 (AC/BAT), minus its battery care/management ability (which doesn’t seem in line with TuneD’s goal) – as far as I looked for now.

That solves my main issue with PPD, and my main issue with TLP’s only-2-profiles. Framework could test/share (like with TLP) as many custom TuneD profiles as needed. For example, extreme power saver (e.g. just reading documents), power saver, balanced, performance without turbo, performance with turbo (e.g. sacrificing battery to finish compiling/rendering as quickly as possible), etc. This would also go hand in hand with the upcoming Framework 16’s numerous configs, e.g. one profile for a specific discrete GPU may not be ideal for another. Exciting, imo :slight_smile:

Battery management is the other missing feature but only tangentially related to this.

Cool. For me all those choices could only possibly be made manually, and I simply don’t want to have to that. Everytime I have tried out other options and have to build the habit to turn on and off battery profile it has not gone well. TLP does this automatically and if you need profiles it is simple enoough to write multiple configs and have a script stop the service and rotate in the new config (profile) and restart the service all while keeping the most important part of the automation whether you are on AC or on BATTERY integral to the service.

1 Like

Yeah it’s one extra thing to keep track of, so basically I only bother switching on battery to a more performant profile when I need quicker performance and then switch back immediately when the job is done. That way I remember, job started, switched to higher energy profile. Job finished, switch profile back. Easy peasy lemon squeezy

It’s infrequent though and context dependent on a lot of external factors like if I need to catch transportation sooner rather than later.

I also tend to always default to some power savings profile on battery (e.g. automatically set when resuming from suspend while on battery). That way, I don’t unnecessarily lose battery when I need it, and if I notice things are a bit too slow, swap profiles temporarily for the task at hand.

Oh hey, thanks for the idea! And saving me from going down the TuneD rabbit hole, for now, lol. I already use scripts to toggle between (waybar), didn’t realize I could just rotate in a completely new TLP config file (derp).

1 Like

There isn’t, it was just recommended to use PPD over TLP for the 7040U frameworks (and they are conflicting packages in arch).

I went through the suggested tunings in powertop, and found the runtime PMs made the most difference (PPD doesn’t set those, TLP did but we are told we shouldn’t use it now).

This just seemed like a lighter-weight alternative if (for me) it gets me 90% of the way there.

1 Like

Just to add some data points for comparison:

Playback of the bunny video mentioned above is 7.5 to 8W using software- and 6 to 6.5W using hardware decoding. Intel i5 1240p, ~25% brightness, fedora 37, mpv.

1 Like

I think this is the right topic, but it appears that the AMD wifi card doesn’t work with suspend-then-hibernate (how are so few people using this functionality???):

Also of note is that if you run kernel lockdown mode (and you should), hibernate is disabled unless you use this patch: Enable hibernate during lockdown · GitHub

2 Likes

A post was split to a new topic: AMD loses battery overnight