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 
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 idleTLP 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! ! ! ! ! !! !!! !!! 
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 
(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
@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
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
At least mention the fact that you wrote the patch, it has not been widely tested or dissemintated, and that you will now be running a tainted kernel.
Not sure myself if this is the right topic, but hey it ain’t completely wrong. As to why so few people use suspend or suspend-then-hibernate well I know for my part I would prefer to shut down in those instances for what are ultimately security reasons. A variety of attacks rely on the device already being powered on and in some form of operation, and yes I do have to concern myself with this to a degree so it is a reasonable precaution. Others likely don’t have these concerns and for them I can only speculate that it is the second reason I never use suspend or hibernate. I have been using linux exclusively for 14 years now, and at no time I remember has either operation worked flawlessly, or without a bunch of manual intervention. Even after it was working it woould break every couple of updates or everytime new processors got added to the kernel. It has to be one the most common “regressions” there is, and the fact that intel and amd both mess with sleep states on a regular basis does not help a bit. So it comes down to knowing what works most reliably for the least amount of effort i.e. this is a fiddly bit that has little intrinsic value outside of a perceived convenience. Back in the day when it took more than 10 seconds to boot I get it, but now the juice is just not worth the squeeze.
Same haha, though it is for Linux and can save battery life. My 2c: suspend-then-hibernate was quite involved with zero knowledge. It can be lot of work (1, 2, 3), and even after that, testing dependability and troubleshooting resumption issues were a pain. That’s with me being a bit lax-security wise (because I understand the implications).
However, since then, it’s been running flawlessly on 11th gen Intel for over a year (through multiple Fedora version upgrades) and (“miraculously”) still works on AMD. It’s been invaluable to me for saving battery as I have my system set to 1. automatically hibernate after suspending for 2 hours and also 2. hibernate at 7%. Therefore, I won’t lose more than 2 hours of battery life %tage on suspend, and shouldn’t ever lose the state I was working on. It also skirts the issue many people had with losing too much battery life overnight during sleep. Sidenote for just hibernation: it has proven immensely useful when I need to boot into another distro to use/test something but don’t want to lose my state, e.g. the rare Windows app. Or even just changing BIOS settings.
It seems there’s been a bump in demand for good UX here since it’s the year of desktop Linux (¿). I’m hoping the Fedora team can figure out how to in Workstation (or whatever distro) so that it can propagate throughout the ecosystem. It does require enough users to provide feedback and testing, so this is also my recommendation to the community try it out (with precaution)! Before, varying hardware configurations made it hard to have a troubleshooting critical mass, but it’s easier here since we run the same or similar hardware.
Maybe we should have a thread dedicated to hibernate/suspend-then-hibernate?
4 Likes