I was curious what the power draw difference was between 165hz and 60hz, so I ran an experiment on my FW 16. My setup is using:
Arch Linux
Wayland for login and user session
SDDM
KDE Plasma
Sitting at the desktop, I draw a steady -7W @ 165hz. In the same scenario, I draw a steady -6W @ 60hz. It’s not the most rigourous test, but for now I’m comfortable in believing that the added power draw for running 165hz is somewhere around 1W. Do note that in this test, there was no activity on screen and so if that makes a difference it would invalidate the test.
Other things of note: this was testing with power-profiles-daemon running. If I run powertop --auto-tune it will furter reduce minimum power draw by ~0.6W.
If someone has a more rigourus test in mind, or ideas on how to test the draw of other components beyond what a powertop calibration is capable of (which isn’t much imo) then I’m all ears.
Overall, I’m so far quite happy with the power effeciency of the framework 16.
Interesting how the different components contribute to power draw, also how the 16 compares to the 13.
Will be configuring for best run time once the time comes, but am set on a 16 despite not being interested in one of the main features (GPU).
Will most likely run Arch, that’s what is on my current Acer 5551 - Athlon II X2, so this will be quite an upgrade
Maybe run a video or a GPU benchmark and see if that changes it? I would think it would still be the same or slightly higher than at idle. My thought behind this is at idle even though it’s refreshing at 165hz the screen doesn’t have to really update and the pixels don’t need to change. With a video or something that changes the screen making it actually refresh may change the required wattage of the screen.
So I tested both refresh rates on a looping youtube video. Total power draw was in the teen’s as the cpu/gpu was now also doing stuff, but the average power draw difference between the two was somewhere around 1-1.5W. So comparable, and that 0.5W could easily fall within the noise of the system granted my power draws were between 13 and 15W during the tests.
I dont know the fine details about how you ran the test but is it possible that some of that wattage could have come from network traffic? I probably should have mentioned it in my other post, but I think the test would be more accurately ran from within the laptop (if that makes sense). Although it would need to access the drive so maybe negligible difference. If you used the same video from the start of the video both times power draw of the system might be higher on the first watch while it caches the video. I’d like to eliminate as many variables as possible if you’re results are from the total system power.
I love that you’re doing this test and I think it’s awesome that it looks like the difference is less than 2 watts. I won’t be getting my FW16 for some time since I’m batch 13 so it’s awesome to see these kind of results ahead of time.
Yes, it turns on autosuspend on all usb/i2c devices. So your touchpad will go to sleep requiring you to click it to wake it up. Same for a USB mouse. Same for anything attached to bluetooth. e.g. when I stop playing audio on bluetooth headsets, and they play a few minutes again later things get stuck. Also the buttons on the headset stop working.
I ran the test on YouTube, but I ditched the first run as it was downloading like you said. I have a bar at the top of my screen that confirmed for me that there was no network traffic during the two tests I did conduct, I believe all the additional power draw was due to the extra processing. I didn’t do any validations on it, but the first run of the test that I didn’t include drew about 20W (165hz, cause that’s what I was on at the time) instead of 15W. 5W seems like a lot of power for wifi… but the other no-network tests were reproduceable so I guess it’s possible.
Powertop identifies a number of parameters in it’s “tunable” tab, my understanding is that the auto-tune simply enables all of those tunables into their power saving state. Like Nickolas says, sometimes this has an adverse affect. The first day I had my Framework, this resulted in needing to wake my keyboard up with a click before using it (very annoying), I have not noticed this behavior on any other components however, and my trackpad works fine.
Curiously enough, my keyboard has since stopped requireing a wakeup click in order to use and I’ve noticed no other adverse effects. My power draw will change by several watts with/without powertop, so I fully intend to continue using it. I do not make use of many bluetooth peripherals however, so your mileage may vary as Nickolas points out.
Incase there’s anyone who’s wondering “why would someone care about just 1W?”. If your average battery draw is 7.5W vs 8.5W depending on refresh rate, that’s the difference of slightly over 1hr of additional battery life.
If anyone is interested in a more rigourus version of this test, I can mix in some local files and external monitors so as to further isolate the display’s power draw from the battery’s aggregate draw. Personally however, I’m satisfied with the ballpark figure.
If we can get VRR enabled for the eDP panel, it would provide better power savings than 60Hz (as it would go down to, e.g. 40Hz) and motion would be at 165Hz, so nice and smooth.
I can’t seem to enable vrr for the eDP panel, but can get it working for an external display over DP.
This is likely because powertop is putting these devices into a power saving mode. I experienced the same behavior, where the first keystroke (after just a few seconds of inactivity) wouldn’t register.
This is what I’ve done to a) persist powertop settings on boot (without using TLP, which would conflict with AMD’s PPD), and b) turn off the “sleep” behavior for the trackpad and keyboard:
Create a file called powertop.service in the /etc/systemd/system directory (you’ll need sudo permissions)
There’s probably a more elegant way to do this (stuffing the 4 echo commands into a .sh script for instance), but this is also pretty legible.
When you run powertop --auto-tune, you are setting the power state (see the power/control part of the device paths) of various devices to auto. You can verify this for yourself by running cat /sys/bus/usb/devices/1-2/power/control (swap out 1-2 for 1-3, 1-4, or 1-4.3 if you’d like, these are all the input deck connectors, with 1-4.3 being the Framework keyboard itself).
So what this modified service file is doing is: after the powertop auto tune has run, we use echo to manually output text, so that the power/control files for those 4 devices are set to an “on” state (so that there’s no wake or missed first keystroke/click).
The ugly looking /usr/bin/bash -c is necessary to invoke the bash shell, since systemd runs outside of any shell.
Reboot your system
You can then run sudo powertop, and hit tab to get to the “tunables” tab. If the service file is in the right place, you should see powertop reporting “Good” for all tunables except the 4 that we’ve manually set to “on”, which will be reported as “bad”.
I’ve been wondering how I could manually tune it automatically like this. Thanks for sharing! Fortunately for me, the issue of the keyboard needing an initial click seems to have gone away, so for the moment the simple --auto-tune is actually working great for me. If I run into the issues again however, I’ll track down this thread.
If there are “specific” tunable items that you can measure help power consumption without sacrificing experience this makes an argument that your distro or upstream systemd or kernel should set such a policy by default.
Could you narrow down the single items that really help? Do a predictable workload that measures something for a period of time, change one option and measure again. It tedious, but this is the data needed to make policy changes.
I’ve never made an upstream contribution, but I see the logic in what you’re saying. I’d certainly be happy to collect this data. It would only be results reflective of one engineer’s machine, but perhaps that’s enough to get a ball rolling. Thanks for the suggestion
I’m trying out NixOS on the Framework 16 (just got it in today). I ran the same tests with this setup:
NixOS unstable branch (for latest PPD, and kernel)
Sway/Wayland Desktop environment
PPD 0.20 in Balanced mode
powertop autotune enabled
brightness at minimum
I got 8.3W at 165Hz, 7.2W at 60Hz, and I actually got a small power saving at 7.9W when I enabled adaptive sync at 165Hz, which seems to work great on this system - haven’t noticed any flickering or stuttering.
I guess Arch is still ahead on power efficiency for now… either that or I messed something up on my installation lol. I’ll keep poking around to see if I can tune it any more, but I’m more than happy with 6+ hours even with higher brightness settings, so I’m not too bothered.
I’ve seen it mentioned somewhere else; watch out what terminal you’re using for testing information. If the terminal app uses GFX rendering it’s going to keep GFX awake while getting the data (increased power consumption). The best information is something captured over SSH from a totally idle desktop.
On my laptop I’ve been experimenting using WARP lately and although I love it; it does increase idle consumption quite a bit because it’s way more GFX intensive than GNOME terminal or Prompt (now known as Ptyaxis IIRC).
