[TRACKING] Linux battery life tuning

Should that affect battery life? I could have been imagining things, but it seemed like my power usage was down after turning that on.

Youā€™re imagining things, system overrides it shortly afterwards.

[    0.087028] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
1 Like

Yeah, I imagined it might be placebo. Do you know if setting the battery charge limit would help? Iā€™m guessing it would with long term battery health.

My understanding is that controls how the system runs while booting, right up until it turns control over to the OS.

1 Like

Has anyone compared tlp and auto-cpufreq? Iā€™ve seen from a reddit thread that auto-cpufreq is actually better. I installed it and removed tlp and seem to be getting lower power consumption.

3 Likes

Sorry for the late response, I donā€™t frequent the Framework forums. Charge limits ruin runtime, but improve longevity.

1 Like

Anyone tried using something like this to configure TDP instead?

The GPU rendering tips for Firefox (Linux battery life tuning) may be out of date for Firefox 100, at least, according to the linked Arch wiki page (Firefox - ArchWiki).

3 Likes

Hi guys

I got my Framework with i7-1165G7 a few weeks ago. I am running Fedora 36 and was optimizing battery life by replacing PPD with TLP 1.5 (powertop is just used for monitoring).
Configuring TLP with the setting

PCIE_ASPM_ON_BAT=powersupersave

brought idle power consumption down to 2.7W without further tweaks (C8/C10 is entered).
Now I get constant audio crackle (like playing some dusty vinyl) during music playback using headphones or internal speakers running on battery. Putting more load with background applications to the system reduces the crackling. Setting the parameter SOUND_POWER_SAVE_ON_BAT to 0/1/10 has no effect but configuring TLP to

PCIE_ASPM_ON_BAT=performance

removes the audio crackling immediately as well as setting RUMTIME_PM_ON_BAT to on from auto:

PCIE_ASPM_ON_BAT=powersupersave
RUMTIME_PM_ON_BAT = on

I think these settings block the system to enter higher C-states resulting in few watt higher power consumption. Any ideas how to solve this? Now I have to trade battery life for audio quality. :pensive:

Thanks!

1 Like

THIS IS VERY VERY VERY IMPORTANT

I WOULD HAVE SAVED DAYS OF WORK IF I WOULD KNOW ABOUT THAT

PLEASE PUT THIS INTO TUTORIAL

https://wiki.archlinux.org/title/Power_management#PulseAudio

I just found out that the audio codec is fine, the CPU is fine and PulseAudio is a reason for all my troubles with audio and power saving. Because PulseAudio doesnā€™t go to sleep by default, it keeps the audio codec awake and the codec keeps the CPU in high C states, and all of that wastes ~6W of power.

But I was f* reverse engineering an issue. From CPU through codec to PulseAudio.

And as always, the answer was in Arch wiki.

1 Like

What about Pipewire? According to other posts, it should be using less power even during usage.

Pulse is pre-installed on my distro and I am using PulseEffects to make eq profiles for my headphones and stuff. I am not sure weather there is equivalent of PulseEffects for Pipewire and I am sure that I donā€™t want to go through setting it up again.

Also Pulse works now, so if it ainā€™t broke donā€™t fix it.

There is EasyEffects and it takes about 3 mins to set up an EQ that makes the audio about 50% better (subjectively). Not saying you should change, just that itā€™s possible.

1 Like

Honestly, Iā€™d rather spend that time figuring out how to use the EQ thatā€™s built in the codec. Then I would not even need PulseEffects or anything and it would obviously save battery.

Codec has like a 12 band parametric bi-quad EQ

1 Like

Set nvme.noacpi=1 in your grub kernel parameters, which results in s2idle suspend battery life that is similar to ā€œdeepā€ on recent kernels without taking the resume time tradeoff. See here for instructions on changing kernel parameters.

On the first comment above, does the kernel parameter nvme.noacpi=1 only affect on the sleep mode s2idle but not on the sleep mode: deep?

By the way, here is nrpā€™s comment about the setting on Hacker News.

Following our setup guides for Ubuntu 22.04 and Fedora 36 (https://guides.frame.... | Hacker News

Following our setup guides for Ubuntu 22.04 and Fedora 36 (Framework Laptop 13 - Framework Guides) we see around 0.8%/hour on 11th Gen and around 0.4%/hour on 12th Gen Framework Laptops in s0ix.|

It only effected s2idle deep sleep was unchanged in my tests.

s2idle with noacpi=1: 0.280 W/h
deep sleep noacpi=0: 0.285 W/h
deep sleep noacpi=1: 0.286 W/h

1 Like

Thanks for your test! Your test shows that the s2idle has a little bit better battery life than deep sleep on the parameter nvme.noacpi=1. Good to know it!

1 Like

Well I would consider it still in the realm of margin of error but I did round the s2idle value up to 0.280 so perhaps! :slight_smile:

Hey yā€™all! Lots of stream of consciousness info coming and too lazy to proofread :), so if something doesnā€™t make sense please feel free to ask me to clarify.

TLDR:

  • Setting an EPP value of 225 seems to be a nice battery/performance balance, but the Intel P-State driver allows you to set whatever you want from 0-255, so itā€™s customizable to your needs!
  • Setting a max GPU boost/frequency of 450MHz at first blush seems like a battery sweet spot, but same idea applies here. 100MHz to 1,300MHz. Set whatever fits your needs.
  • Iā€™d currently advise against using power-profiles-daemon if you need anything between EEP values of 255 (power) (PPD power-saver) and 128 (balance_performance) (PPD balanced).

So I got a chance with the long weekend to spend some time diving back into battery life tuning, especially after reading reports of some people getting 8-10 hours of battery with light workloads.

Did a bunch of this and that, and from some short tests, I think itā€™s very possible now to achieve that. Thereā€™s definitely been some kernel improvements since I last did a thorough test back in Sept or whatever, but some things that I didnā€™t see mentioned, though tangentially touched upon (kudos to the all the effort in this thread!) which I think are gamechangers:

CPU Energy Performance Preference

https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html#energy-vs-performance-hints
The Energy Performance Preference (EPP) ā€œknobā€ is where the most energy savings will come from.

# NOTE: (fish shell allows me to use the `*` wildcard in `cpu*`to affect all cpu number directories
# I'm not sure how to do it succinctly in bash etc., though I know a for loop works
cat /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_available_preferences

As we all probably already know these are the values that can be set:

default performance balance_performance balance_power power

However, from the documentation (and I havenā€™t seen it mentioned anywhere else! Not TLP nor power-profiles-daemon documentation)

The values we can set can also be numeric (0-255) (most to least performance) (most to least energy use) and written like so (as detailed in the above intel_pstate link):

echo "225" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference

These 4 numbers when written translate like so:

Number EPP
0 performance
128 balance_performance
192 balance_power
255 power

Which translate roughly to these frequency limits:

EPP Number Notes
performance 0 boosts to ~4.0GHz, then stays at ~2.8Ghz. Supposed to boost up to 4.7GHz per specs I think? Eh, this is a thread about optimizing battery life, anyways.
balance_performance 128 boosts to ~3.8GHz, then stays at ~2.8GHz
balance_power 192 boosts to ~3.1GHz, then stays at ~2.8GHz
power 255 limits the CPU frequency to ~1.6GHz. This is noticeably laggy ā€“ good for reading, but not for compiling code/ā€œmultitaskingā€ etcā€¦

So we can see that thereā€™s definitely some optimization to be had between the most energy efficient power mode (1.6GHz) and the next balance_power mode (2.8GHz).

Generally, more energy is used with higher clock speed, meaning an increase from 1.6GHz to 1.7GHz uses much less energy than 2.8GHz to 2.9GHz. This is why disabling Turbo on battery is likely a good idea. Thereā€™s also the argument of consumption between race-to-idle and pace-to-idle, but Iā€™d say with rogue/energy-intensive JavaScript sites (even Reddit with autoplaying video), itā€™s probably a good idea to cut off the top-end frequency where energy consumption is very high.

Iā€™ve found that setting an EPP value of 225 (between power (255) and balance_power (192)) will limit the frequency to ~2.3GHz. This is noticeably faster than 1.6GHz, less energy consuming than 2.8GHz, and seemingly enough for most tasks. At first blush, it seems optimal for my ā€œon batteryā€ needs. Web browsing/coding/working equates to ~= 5-7W roughly? I havenā€™t tested thoroughly yet, but will as I plan to work more on battery.

Of importance: power-profiles-daemon got rid of the balance_power mode for now:

So a user has to choose between the slow power mode and the higher energy demand balance_performance mode. Terrible for optimizing battery life.

I recompiled PPD to use power, balance_power, and balance_performance (@me if you want the patch), but ended up just switching to TLP. It doesnā€™t seem to be in the docs, but itā€™s possible to set any EPP value from 0-255 like so:

/etc/tlp.conf

# Set Intel CPU energy/performance policies HWP.EPP and EPB:
# performance, balance_performance, default, balance_power, power.
...
CPU_ENERGY_PERF_POLICY_ON_AC=balance_performance
CPU_ENERGY_PERF_POLICY_ON_BAT=225
### Note this value is numeric ^

Also, the same ideas apply to the GPU as well:
/etc/tlp.conf

# Set the min/max/turbo frequency for the Intel GPU.
...
INTEL_GPU_MIN_FREQ_ON_AC=100
INTEL_GPU_MIN_FREQ_ON_BAT=100
INTEL_GPU_MAX_FREQ_ON_AC=1300
INTEL_GPU_MAX_FREQ_ON_BAT=450
INTEL_GPU_BOOST_FREQ_ON_AC=1300
INTEL_GPU_BOOST_FREQ_ON_BAT=450

You can see how limiting GPU max/boost frequencies affect power usage/framerate/performance with this:
http://www.kevs3d.co.uk/dev/shaders/

But the above settings (I havenā€™t tested long-term yet) seem to have a large impact. With the Mountains (in the sunset) demo:

Limited to 1300MHz I saw usage go up to ~20W. FPS ~18.
Limited to 450MHz I saw usage go up to ~10W. FPS ~55.

Limiting the GPU doesnā€™t make sense if you need the graphics power, but for just web browsing/coding/etc., it can significantly limit bursts of unwanted battery drain, e.g from website videos/ads. It also may make sense for watching videos, though from what Iā€™ve seen, the GPU already does a good job at clocking down.
Related sidenote: for 1080P video playback I was able to get down to 5.5W on 1% brightness, 75% speakers, wifi/bt on ā€“ thatā€™s an actual 10 hours of playback! MPV/VAAPI HW decode. Round down to a solid 8 hours at higher brightness.

Miscellaneous

Specs:
i7-1165G7, 64GB G.Skill 3200Mhz, 2TB SK Hynix P31
Fedora 5.17.11-300.fc36.x86_64 with Sway 1.7
Seems like Sway uses slightly more battery than Gnome 4x, could just be my installation, though, and the tradeoff imo is worth it anyways.


Seeing the reports that Ubuntu 22.04 has low idle usage, I tested it out stock on my system. Idle was very low (down to ~2.4W), and mucking/browsing/clicking around with 1 or 2 tabs in Firefox was about 4-6W, roughly.


Itā€™s been a while since Iā€™ve daily driven Windows, but one can set EPP values there with ThrottleStop.


Lastly a nice tip for those that like to stream music in the background while working:

This plays a YouTube stream in the background with no-video. Uses very little energy ā€“ very-much-way-more-less than streaming in a browser, especially with the still :pensive: poor Linux browser VAAPI support.

yt-dlp -q -f 91 -o - "youtube video url, can even be a livestream" | mpv --no-cache --no-video -

Iā€™m curious to see how 12th gen energy usage will compare to 11th gen at the same performance .


Cheers! :melting_face:

23 Likes

@Michael_Wu , fantastic write up! I already have my setup well tuned with tlp, but itā€™s really nice to know thereā€™s that easy of a knob to tweakā€¦

The P31 SSD really seems to help, I highly recommend anyone shopping for power efficient parts go with that one, despite itā€™s slightly higher price and lower availability.

1 Like