This will actually cripple performance.
Teams is undoubtedly adding to your battery life misery, it would not matter what CPU especially once video conferencing kicks in.
Also try using TLP instead of PPD, you have nothing to lose and everything to gain. Disable turbo on battery in TLP and you should see vast improvement. Personal take on PPD is that it is hot garbage for actual battery life.
I get better Battery life with powertop.service --auto-tune ; and the patched PPD supporting epp hints, than I have with TLP. With considerably less mucking about with default system integrations for what itās worth.
The main issue is really around what provides OOTB integration for most users with the two main DEās (Plasma and Gnome). Which PPD does a much better job at currently; would be great to see TLP step up in this space. Tuned looks to be gearing up to provide some of the same interfaces ppd does as well, would be nice to see TLP advance in this area too.
The only thing PPD is really providing is an easy way to use multiple profiles. TLP simply uses the state either you are on AC or you are on Battery. Tuned is basically PPD on steroids, but the documentation sucks. For a desktop or server I would probably use Tuned maybe even PPD and not TLP. When it comes to actual battery life TLP generally wins, also usage with docks, i.e. with laptops.
So what are you averaging on battery life?
Most of the gains have come from 6.7 branches with patchwork patches applied and Mesa 2.4.
with 6.7-rc2 and the pref-cores patches I idle at 2.3W under plasma (with backlight at 1%) and BT off - wifi on. and around 4.3W with actual work going on in Firefox and a konsole open.
Using powerstat timed runs for consistency in comparisons.
With the FC39 default kernel and/or 6.6 kernels Idle is around 4.6W and 5.6W usage under same scenarios. Again with just powertop.service auto tune bits and the patched multi driver PPD to set hints. I AM using the kde plasma centre integrations with PPD to switch screen brightness power profiles on battery/ac state change .
Yep, Iāve tried and seen for myself. Whatās more, the impact on power consumption was not noticeable at all.
Iāll try TLP and see how it goes, just gotta find the documentation explaining how to disable turbo on battery 
Thanks!
@jwp as you talk about plasma, I was wondering if it is still an issue to install any other flavor than the workstation with Gnome ? So, are you using KDE Plasma DE installed on top of Fedora Workstation 39 or did you install Fedora 39 KDE spin ?
From your experience, is KDEās DE more power friendly than Gnome ?
Iām not very tech savy so just wondering if you did some tricks to make it work or if it works out of the box with the new 3.03 Bios now ā¦
Issues with Plasma?
The only issue iāve had with Plasma is a weird bug in resolution changing the default output in kwin_wayland (and itās not really that big of deal given you shouldnāt try and deviate from native EDP panel resolutions anyway; and use scaling / FSR to achieve the same).
Iāve done both install the spin and switch from default fc39; This install was just workstation and then dnf install @'KDE Plasma Workspaces' followed by optional switching to sddm dnf install sddm; systemctl disable gdm.service; systemctl enable sddm.service
I donāt use Gnome sessions much - but the default Energy Centre and configurable profiles in Plasma are definately much more flexible and configurable than Gnome45 without extensions or manual poking.
I mean, not really issue with plasma itself but about using the spin. Matt was always telling people reporting issue to not install the KDE version because of the no support, or at least install KDE like you did on top of the default Gnome DE. I would have though that the core of fedora and the settings would have been the same accross any version but somehow it did not seem to be the case. Or did I misunderstood something ? Thus my question.
Shrugs possibly to do with fwup differences in userspace and advising people through initial bits would mean taking different screenshots.
Both work just fine.
And I just want to put to bed ths TLP debate.
Look - if you are running Not a DE (like the gist linked above and reports; Sway is a wlroots compositor framework ; NOT a Desktop environment) and you have hacked at a base distro install and/or built it from scratch without freedesktop components/testing etc. Sure you can probably squeeze some mwās out of a base install.
BUT for everyone else.
Switching to TLP has little to no (or in my tests, actually adverse) mw tuning options over using the shipped distroās approach + one or two fixups.
TLP does however introduce a lot of āunhappy eyeballā effects ; namely using TLP means that brightness sliders/dim etc in powerdevil which work just fine normally - no longer work as well as several other noticable lag effects during login management/switching ttyās etc and needing to add selinux policy/audit fixups for the things TLP wants. It also requires compiling and installing (which admitedly you will need to do for the mutli-driver PPD approach for best result)
First screenshot is exactly the same kernel and system with nothing but udev rules fixups for usb and pcie/aspm policy added and the same platform and epp hints and powertop --auto-tune service set up. With PPD multi-driver 0.13 patched.
Second is the same kernel/tuning bits and system with PPD disabled and TLP enabled (after powertop.service --autotune so itās doing whatever it likes to the tuneables powertop might have set). Using the linked @Michael_Wu gist TLP.conf (with a change to the performance profile to be balanced) @
Exact same workload / environmental etc.
tl;dr
PPD: Mean 3.69 , Min:3.17, Max:4.15 stdev:0.42
and
TLD: Mean 4.10 , Min: 3.30,Max:4.43 stdev:0.37
Hi @jwp,
Thanks a lot for this! Would it be possible to summarize the changes needed that you mentioned? I know youāve written about them in multiple places, but Iām having a hard time sorting out which of those are superseded by new findings etc. Itās also a bit unclear to me which changes are expected to come in future updates and which ones might never arrive in mainlineā¦
That is definitely encuraging
on arch with kernel 6.6 I can get it to idle at around 2.8-2.9W at min backlight with bt on and wifi connected, wifi on is somehow worse XD. 2.3W is a value I have never seen under any scenario.
Do those patches have an impact on the hardware decoding power consumption?
I am kinda tempted to try that myself got a list of all the patches that helped?
Iāve only seen 2.3W is with screen off.
So that one is a typo? You meant 3.3 or something?
Yes or an outlier that stuck in my head from a series run. 3.5W with what is around currently seems pertty obtainable at idle, 4W seems more normal. Actually doing things 5-6W.
Well that put a bit of a damper on my enthusiasm to try the 6.7 rc, probably still will though.
I may have missed something, are we expecting major improvements on AMD chips with kernel 6.7?
as thereās a lot of you guys trying all the things for tuning, make sure you take a look at this:
Adaptive Backlight Management (ABM) - Framework Laptop 13 / Linux - Framework Community
Gonna give this a shot right after I rerun my test on the 6.7 rc so I donāt test too many variables at one.
Though the difference between screen at min and screen at my testing 20% is less than 1W so the possible gains there are limited. But I take what I can XD.
Given how it works Iād expect the bigger improvement when you have brightness āsetā higher itās not as much of a trade off for power consumption. But yes you need to capture brightness level and use the same ācontentā to confirm it.
The AMD testing that shows that number I quoted is specifically measured with video playback.
