Query did you turn turbo off on battery with TLP? This is the biggest difference between the power profile crowd PPD/Tuned and TLP. PPD and Tuned try to use turbo to “enhance your user experience” and kill the battery.
1 Like
Well you do seem to be casually running teams in the background and calling it idle sometimes XD
My setup is arch on kernel 6.6 running sway. I did also switch to an ax210 instead of the mediatek but I never got around to doing proper a/b testing on that part.
I left that on
Wrt Decode usage - do you get differences between mesa git repo?
Probably why I see a huge difference between the two. The machine is still ridiculously responsive and fast on battery for the work loads I am performing on battery. So the slight performance hit is something I am willing to live with while on battery since it is barely noticeable to me.
1 Like
In what scenarios did you see significant differences?
I am not going to go into exhaustive detail as to what my setup is and what I am doing as it has been posted multiple times in this thread alone. Suffice to say when on battery PPD would be lucky to get down into the high 6.90+ range as the lowest it would go and it would take some time getting there, with TLP with turbo off on battery I get down to 4.53w regularly and qucikly. TLP idled quicker and hasin field testing lasted me up to 2 hours longer than PPD.
I am running Fedora 39 Workstation on a 12th gen Intel i7-1260p FW13, 64GB RAM, 2TB SKHynix P41 nvme, all usb-c modules, matte display at 30%, with firefox, evolution, terminal, and quod libet running via headset, buetooth is off. I regularly get 9+ hours out of it on battery with TLP, with PPD as low as 6 hours without changing my usage pattern or behavior.
1 Like
Hi, a critical use case for me is being able to work for a full day without mains. First setting up my FW13, it seemed like it wasn’t going to be possible, however with a little tuning, things are looking much better.
As @jwp noted here and in the above posted thread, there are still some kernel fixups for amd pstate in process.
I’ve run some preliminary benchmarks via PTS and so far am seeing strong cpu/gpu performance. I’ll post results as I have more.
In your shoes, I would
a) install and run powertop to see what’s draining your battery
b) config my system as detailed in the above thread or at very least with:
PPD set to power-saver, EPP set to power (or balance_power), USB autosuspend enabled
c) run some tests for 10% battery or more to evaluate energy draw
d) for perforumance, move to at least balance_power EPP, run benchmarks of interest to you (bound to cpu, gpu or both)
e) make an informed decision about whether the FW13 fits your needs or not
Hope this helps!
3 Likes
Hey @jwp, I have 6.7.0-rc3 with the perfcore patch set on Arch Linux but still seeing ~5w idle power consumption (with screen on but at min brightness)…
Time User Nice Sys Idle IO Run Ctxt/s IRQ/s Fork Exec Exit Watts CPU Freq Freq Min Freq Max
01:10:29 0.2 0.0 0.2 99.6 0.0 1 720 594 9 2 4 5.44 0.63 GHz 0.40 GHz 2.17 GHz
01:10:39 0.2 0.0 0.1 99.7 0.0 1 691 555 2 0 7 5.37 0.62 GHz 0.40 GHz 2.07 GHz
01:10:49 0.1 0.0 0.1 99.7 0.0 1 662 523 0 0 0 5.31 0.44 GHz 0.40 GHz 1.40 GHz
01:10:59 0.1 0.0 0.2 99.7 0.0 1 623 494 0 0 0 5.31 0.72 GHz 0.40 GHz 2.28 GHz
01:11:09 0.2 0.0 0.2 99.6 0.0 1 749 598 0 0 0 5.32 0.40 GHz 0.40 GHz 0.40 GHz
01:11:19 0.2 0.0 0.2 99.6 0.0 1 667 530 0 0 0 5.31 0.49 GHz 0.40 GHz 1.40 GHz
01:11:29 0.2 0.0 0.2 99.6 0.0 1 659 518 0 0 0 5.31 0.40 GHz 0.40 GHz 0.40 GHz
01:11:39 0.1 0.0 0.1 99.8 0.0 1 487 382 0 0 0 5.25 0.40 GHz 0.40 GHz 0.40 GHz
01:11:49 0.2 0.0 0.1 99.7 0.0 1 588 464 0 0 0 5.27 0.73 GHz 0.40 GHz 2.28 GHz
01:11:59 0.2 0.0 0.2 99.6 0.0 1 701 691 9 2 3 5.23 1.05 GHz 0.40 GHz 2.28 GHz
01:12:09 0.2 0.0 0.2 99.7 0.0 1 710 597 2 0 8 5.37 0.40 GHz 0.40 GHz 0.40 GHz
01:12:19 0.1 0.0 0.1 99.8 0.0 1 608 493 0 0 0 5.39 0.45 GHz 0.40 GHz 1.45 GHz
01:12:29 0.1 0.0 0.1 99.7 0.0 1 559 435 0 0 0 5.37 0.40 GHz 0.40 GHz 0.40 GHz
01:12:39 0.4 0.0 0.5 99.1 0.0 1 1510 1966 66 30 60 5.65 0.40 GHz 0.40 GHz 0.40 GHz
01:12:49 0.4 0.0 0.5 99.1 0.0 1 1472 2213 0 0 0 5.88 0.55 GHz 0.40 GHz 1.40 GHz
01:12:59 0.3 0.0 0.5 99.2 0.0 1 1441 1729 23 7 23 5.88 0.90 GHz 0.40 GHz 2.13 GHz
01:13:09 0.2 0.0 0.4 99.5 0.0 1 650 522 0 0 0 5.67 0.87 GHz 0.40 GHz 1.99 GHz
01:13:19 0.2 0.0 0.3 99.5 0.0 1 559 463 0 0 0 5.59 0.69 GHz 0.40 GHz 1.81 GHz
01:13:29 0.2 0.0 0.4 99.4 0.0 1 692 570 0 0 1 5.55 0.44 GHz 0.40 GHz 1.40 GHz
01:13:39 0.2 0.0 0.4 99.5 0.0 1 580 482 1 0 0 5.49 0.40 GHz 0.40 GHz 0.40 GHz
01:13:49 0.2 0.0 0.4 99.5 0.0 1 578 484 0 0 0 5.46 0.45 GHz 0.40 GHz 1.53 GHz
01:13:59 0.2 0.0 0.3 99.5 0.0 1 570 459 0 0 1 5.45 0.49 GHz 0.40 GHz 1.40 GHz
01:14:09 0.1 0.0 0.4 99.5 0.0 1 552 456 0 0 0 5.41 0.49 GHz 0.40 GHz 1.37 GHz
01:14:19 0.1 0.0 0.3 99.5 0.0 1 642 520 0 0 0 5.43 0.54 GHz 0.40 GHz 1.37 GHz
01:14:29 0.2 0.0 0.4 99.5 0.0 1 600 474 0 0 0 5.40 0.67 GHz 0.40 GHz 1.40 GHz
01:14:39 0.2 0.0 0.3 99.5 0.0 1 545 452 0 0 0 5.40 0.45 GHz 0.40 GHz 1.52 GHz
01:14:49 0.2 0.0 0.3 99.5 0.0 1 658 535 0 0 0 5.42 0.49 GHz 0.40 GHz 1.40 GHz
01:14:59 0.3 0.0 0.4 99.3 0.0 1 849 682 10 2 4 5.49 0.49 GHz 0.40 GHz 1.40 GHz
01:15:09 0.2 0.0 0.4 99.5 0.0 1 628 518 3 0 7 5.51 0.60 GHz 0.40 GHz 1.40 GHz
01:15:19 0.3 0.0 0.4 99.4 0.0 1 941 697 0 0 2 5.56 0.51 GHz 0.40 GHz 2.00 GHz
[root@framework amd_pstate]# cat /sys/devices/system/cpu/amd_pstate/prefcore
enabled
Do i need any more tlp/sysfs tweaks to get it down to ~3-4W?
Use the patched version of PPD to set multi profiles (epp and platform hints) and/or use another methods to switch them (only ever should have power, low-power for bat, and balanced_performance, balanced for AC). Set auto suspend udev rules for pci and usb . Dim screen etc should be set using whatever userspace tool (in kde it’s powerdevil integrated with energy centre). Disable BT when on Bat (unless you use it).
I have
pcie_aspm.policy=powersupersave amdgpu.abmlevel=3 iomem=relaxed amdgpu.ppfeaturemask=0xffffffff
as my kernel cli which does much of what TLP trys to do with userspace tuning. I have as mentioned far worse stability and performance with whatever tlp does over and above the above tunings which work fine with xdg desktop integrations through ppd mutli-driver patched.
I don’t know if the cros_ec_lpc patch is actually useful, but I am running it with all the kernels I have and it MAY expose some tunables via default userspace bits which get fiddled it may not. I haven’t investigated too much.
I also have the uip timer patches in my builds
@David_Markey ; oh do you fail to get als with 6.7-rc3 I think there is a regression in the init code for usb_sensor_als - you’ll see dmesg output grepping for als and that the iio bus device is not populated.?
this is dependent on your workload though. as a college student, my workload is generally something like: a couple of firefox tabs, neovim open in my terminal emulator, and maybe a document in libreoffice. my power draw is going to remain fairly constant over time - there is no heavy job that can be finished faster.
it’s late and i’m not very coherent right now, but i hope you understand what i mean?
Can I ask if you tried using Intel Performance and Energy Bias Hint and limiting P+E core frequency to push the frequency back into the efficiency curves?
1 Like
I use the default HWP.EPP. EPB is not set when HWP.EPP is available. This topic has a good explanation from the principal developer of TLP as to why TLP not setting EPB / Laptop Issues / Arch Linux Forums . Post #8 and #9 specifically.
The only items I change from the default are as follows:
CPU_BOOST_ON_AC=1
CPU_BOOST_ON_BAT=0
CPU_HWP_DYN_BOOST_ON_AC=1
CPU_HWP_DYN_BOOST_ON_BAT=0
USB_DENYLIST= (Device id’s related to assorted docks I use with the laptop)
USB_EXCLUDE_AUDIO=1
USB_EXCLUDE_BTUSB=1
DEVICES_TO_ENABLE_ON_AC=“bluetooth”
DEVICES_TO_DISABLE_ON_BAT=“bluetooth”
DEVICES_TO_DISABLE_ON_LAN_CONNECT=“wifi wwan”
DEVICES_TO_ENABLE_ON_LAN_DISCONNECT=“wifi”
That is all of it. I run TLP in conjunction with Thermald. I tried a lot of different methods of getting the longest battery life I could given my workloads, and a wide variety of tools. In the end TLP won out because it worked as expected all fo the time. My numbers hit idle states very quickly, my actual battery life vs estimated battery according to powertop line up very closely. Also the juice was simply not worth the squeeze when it came to further tweaking. Sure I might be able to squeeze out more but then I am looking at possibly disabling Secure Boot (yes I know secure boot is of questionable value but I tend to run my stuff at home close to what I run at work outside of the distro), or runnning with a Tainted Kernel (again another who might care, but once again, I want to keep it close to stock).
In this situation I simply drop a configuration file I have used for a very long time in place in /etc/tlp.d/ and forget about it. Done. No stability issues, no forgetting what knobs I might have twisted, no short battery run times, no noise issues, no heat complaints, it all simply works as intended with minimal effort on my part and this essentially works with any laptop I jump on or get a hold of that is less than 10 years old. In short two minutes and I am running.
1 Like
[ 5.299323] hid_sensor_als HID-SENSOR-200041.1.auto: failed to setup attributes
[ 5.299328] hid_sensor_als: probe of HID-SENSOR-200041.1.auto failed with error -1
Yes getting some error alright…
Would you be able to point me at the UIP patch sets, and where could I obtain this patched version of PPD you mention?
Wow, thanks!
I have the same system as you so I wanted to tweak it and was looking for something simple.
I was looking through your posts, and from what I gathered, you didn’t bother with changing the CPU governors as it might not really make a difference? I see that TLP allows a fast time to reach idle so I thought it is fine.
Regarding CPU frequency limiting, I was reading an article stating that Intel pushes both cores out of their efficiency sweet spot as the default behavior, where the e cores get pushed to be even more inefficient than p cores. So I was wondering if adjusting them back to the sweet spot, would it be better?
Gracemont E cores below 3GHz, Golden Cove below 4 GHz.
After years of playing with this sort of stuff for fun, I came to the conclusion that letting the kernel handle stuff is usually the best thing you can do. Sure you might be able to squeak our a little extra…except it then breaks because of a change you missed…and then it is time to go on a hunt trying to figure out why your changes are not working. Also limiting freqs directly I found hampers performance to such an extent that the extended work time actually kills battery life.
3 Likes
That’s a fair point. I guess I will skip that then.
I was just thinking from the point of view similar to desktop where I limit TDP which loses like 5% performance for like 20 degrees and 20% less power. So was trying to apply it similarly here where we push it back to the efficiency curve so we lose a little performance but get much better thermals and consume less power.
Thermald basically does that. It uses DPTF by default, which essentially puts a mild throttle on the CPU … i.e. it performs the way the manufacturer designed it to perform, and under these conditions it runs very well by default. It is performant, runs reasonably cool, and mostly quiet. Turbo is the only thing that really prevents it from being a viable option on its own, because Turbo pushes the frequencies beyond the point of efficient usage for a brief extra bit of perfromance, at the cost of a lot of power. Great when you are plugged in and probably don’t care about power draw, extra heat, and extra noise.
1 Like
I just realised the base frequencies are at the range that makes them work efficiently.
Thanks for the discussion. Now all that is left is for me to get back my Framework i7-1260p laptop once my relative is done with his course.
That being said, I am kinda excited for Meteor Lake if the battery life is even better without tweaks with a much better iGPU.
1 Like
That is the buzz. I think the 15th gen is going to make Intel Mobile truly competitive again across the board. I went 12th gen instead of waiting for an AMD one because Thunderbolt was/is that important to me, and assurances that USB4 is comparable just did not cut it.
1 Like