Similar descriptions are missing for the linux distro configurations.
Did you apply the PPD optimizations before testing?
Does Linux enable smart access memory?
I actually found on windows, disabling SAM reduced a ton of stutter in several games, even if the overall frame rate dropped slightly.
Could try testing with SAM disabled to see if Windows does any better. Then again, it’s 11, there’s always the possibility it’s just Microsoft’s latest phone home nonsense spinning up in the background too.
You should ideally be noting versions you use for the kernel PPD, and mesa for each of your Linux tests because these have a BIG impact.
Also did you make a mistake in Arch? 67W idle seems high.
Lastly windows enables ABM by default, you need a new enough PPD and specific kernel patches for this in Linux.
3 Likes
Sorry, I completely blanked on adding that. I’ll edit the original post to clarify. Fedora and Ubuntu were running their stock kernel, and Arch was running the official linux-zen package. I’ll double check the exact versions before I add them to the original post.
All of the Linux installs were running PPD exclusively (no powertop/autocpu-freq/tlp). They were run in balanced mode unless otherwise specified. I did note that power saver mode didn’t seem to have much impact in the tests that I did. I think different tests would better show the differences between each mode better.
I’m not sure about that. I imagine that one could get windows running smoothly under similar conditions, but I didn’t take the time to debug it at all other than just running the test and moving on. I might come back to that in the future if I decide I want to run Windows on it.
That was a typo, it should be 6.7 watts, or really just rounded to 7 watts with the accuracy of my tests.
As for the versions of each component, I’ll go check, and add that information to the original post. I didn’t do any kernel patching, or any custom packages for PPD because I was trying to see the default power consumption on each system following the official install guide (if available) without much tweaking. I also saw that Arch just pushed linux 6.8 to stable right after I tested, so that might have some effects as well.
what software do you use to view the wattage in fedora? and have you tried to see if the curve optimizer would work to undervolt the cpu?
Great work putting this together! You’re results are more-or-less consistent with my own testing under basically the same methodology except I use power saving profiles instead of balanced and I don’t have a dGPU module. On my Arch install I see about 6W draw for 60hz and 7W at 165 during idle. It’ll dip as far as 5.4W, but I’ve never seen it go below that on Arch.
Arch:
- PPD v0.2
- KDE Plasma 6
- Kernel 6.7.9
I recently experimented with installing Gentoo however (which took me several days admittedly), and had some interesting battery findings. Once I got PPD and Plasma setup, my average idle draw was ~5W with semi-regular dips to 4.8W. This leads me to believe that there are still opportunities for optimization on Arch, but unfortunately I’m not certain where the power draw difference comes from. It could be due the nature of all applications being complied on-and-for the framework specifically, but I’m not certain. If I unplogged the expansion modules, I could reduce power draw by an additional 0.2W, down to 4.6W.
Gentoo:
- PPD v0.2
- KDE Plasma 5.x
- Kernel 6.8.1
I didn’t know about btop, I’ve been using powertop and polybar to gather usage stats. This app is awesome! Sharing the same interest for battery efficiency, I put together a minimum power-draw competition. Perhaps you’d be interested in participating.
4 Likes
Yeah, I think for your use case of finding the absolute minimum power consumption, powertop may still be better… not sure how cpu efficient btop is compared to powertop as I regularly see it using .5 to 1.5% cpu (even if the frequency doesn’t go above the minimum 400MHz).
I did a bit of testing to see how low I could push power consumption, but I’ll post that over on your thread.
1 Like
PPD 0.10 and 0.13 from Ubuntu 22.04 and Fedora 39 respectively are missing support for CPU + Platform together, so I expect that’s at least part of the reason for the difference to Arch.
You can use my PPA on Ubuntu and if you do the Fedora 39 normal updates to get 0.20.
Hopefully with 0.20 you get more consistent results.
There is also another change added after 0.20 that’s not yet in a released version for making balanced behave differently on AC vs Battery. FYI this is in my PPA but not in Fedora.
3 Likes
I did some testing on my Arch install. If I optimize arch down to 5.3W of usage, I can further decrease power draw by 0.8W by removing all usb-modules, keyboards, and tracpad. Thus I think it’s reasonable to say the sum draw of those components is about 0.8W
Additionally, under this same setup I experimented with the (US English) keyboard at full brightness vs lighting off and was surprised to find a 1.9W difference! The keyboard backlight seems to draw nearly 2W on it’s own.
Another thing I’ve noticed during some additional testing, is that when I powertop --auto-tune on my Arch install with KDE, I don’t get any of the keyboard/tracpad wakeup issues, but on the same config if I close the graphical environment and operate in TTY that issue returns.
2 Likes
That’s a good point. I am a little surprised framework doesn’t even mention this in their official installation guides as the newer kernels and PPD versions seem to have a really meaningful impact, and presumably will have even more impact when the abm patches are integrated in 6.9 (hopefully?).
I would imagine it’s not called out for the sake of simplicity. Those who really want to know, will, and those who don’t will eventually get the changes anyways once they get through the process.
I’m running Arch Linux on my FW13 (I don’t have an FW16), I noticed that during 1080P youtube streaming, switching to full screen makes the power consumption goes from 12W to 20W(consumption is a bit higher due to measuring USBC power input), so what’s the problem with youtube (no consumption increases in video playback on VLC)? and OP could you please publish video playback both windowed and fullscreen and compare them?
What platform are you using on the framework 13? Intel or AMD? It could be several different things, but my first guess is that hardware decoding isn’t working on your browser specifically since vlc isn’t consuming as much power. See these arch wiki article for some more details:
firefox specific: Firefox - ArchWiki
chromium specific: Chromium - ArchWiki
In general, it is easier to get working on Firefox in my experience - just a single option in the about:config page, but both can be made to work. The power consumption should be basically equivalent between fullscreen and windowed playback at the same resolution. I just did a quick test on the FW16, and fullscreen playback was actually .5W cheaper (probably just system noise though).
1 Like
I already installed libva-mesa-driver and mesa-vdpau, enabled gfx.webrender.all and media.ffmpeg.vaapi.enabled. In the about:support the Compositing is WebRender, however I also saw this
there are lots of “Unsupported”, how can I enable support these?
However this does not explain the discrepancy of windowed vs fullscreen, I discovered that the Miniplayer function increases the power consumption as much as fullscreen, I guess that something is wrong with LXQt, maybe I should use GNOME instead
Anyone with the 7940 do an undevolt? If you do, what’s the power savings (if any noticeable), and performance difference.
Trying to decide if it’s worth waiting longer and cancel my exiting 7480 and get at the back of the line for 7940.
Hmm, yeah I’m not sure then. Youtube is usually serving either vp9 or av1 these days, so you should be good on that end. I’m not sure why LXQT would have an effect, but its worth trying another DE if you think it might be the source of the issue. I’ve observed normal fullscreen playback power consumption on arch on gnome on both my framework 16, and my 11th gen intel framework 13, but I don’t have any insights other than that.
Double checked with Fedora 39 (still on FW13). Now both windowed and fullscreen 1080P youtube streaming consume about 12W(measured from USB-C input voltage and current). However when moving the mouse to show the progress bar, the consumption will go to 21W. I guess it’s indeed GUI related
There is some very deep work going on that will improve how compositors blend planes together. At least with scanout configurations (how you would nominally want to show video for low power playback) this will improve consumption significantly.
Here’s the ongoing work for the lowest layer stage - how the GPU driver will change cursor blending:
There’s some links in this thread as well for the changes being made in libraries and compositors as well.
7 Likes
I discovered that in Fedora, compared to 100% setting the displays scale to 200% increase the powerconsumption about 10% and 125% to 175% increase the consumption about 40%
4 Likes
Is it possible this is not an issue with Fedora per se, but rather the desktop environment? I’m not showing any noticeable difference in power consumption between 1.0 and 1.5 scaling in Sway on Fedora 39.
1 Like