Extending laptop battery life: what does it take?!?!

Hi. I’ve got a Framework laptop here with a 12th-gen Intel chip. Here’s a non-exhaustive list of things I’ve tried to reduce power usage:

  • EndeavourOS’ default powerprofilesdaemon power saver mode.
  • Disabling cores and messing with the multiplier in UEFI.
  • powertop --auto-tune
  • Changing “perf-bias” with cpupower
  • tlp, with power-saving tweaks to every setting I felt I understood enough to change: CPU_MAX_PERF_ON_BAT=20, CPU_BOOST_ON_BAT=0, CPU_HWP_DYN_BOOST_ON_BAT=0, PCIE_ASPM_ON_BAT=powersupersave. I have confirmed this service is running.

Nothing has really put a dent in it: power usage, according to powertop is around 10W no matter what. This is in normal usage, like web-browsing without streaming video, with a few background applications like a music streaming service and Discord. The outcome is that battery life around 4 hours. With video streaming, power consumption goes above 12W. With truly nothing, on boot, it’s 6-7W. Screen brightness is at or near minimum. For reference, some other linux users with this laptop claim to get power consumption under 5W, and battery life close to ten hours with regular use.

What do they know that I don’t?!

There is never “truly nothing”, even if you booting into a TTY without network, you still have a bunch of processes running. Speaking of which, have you tried that? No GUI, no network? I’m just curious what powertop gives you in that case.

Who? YouTube doesn’t count, most of them are ignorant and/or liars.

That sounds pretty good to me. I’m happy if I get 2 hours on my old laptop (running Arch) which has a new battery. And on the company laptop I use for work (that runs windoze 10), I am happy if I get 45 minutes :rofl:

You can get some work done in 4 hours and unless you’re really out in the wilderness, that should be more than sufficient amount of time to find a place to plug it in and recharge it.


I seem to recall that power profiles daemon cannot be used together with tlp.

Yes, I used them separately.

Multiple people on the framework forums. You can see here in the battery thread that there’s a striking breadth of outcomes, with some people reporting my trouble, an others reporting astoundingly good results.

what’s the consumption on windows?

also you should ask those people who claim 5w drain. who knows how they crippled their system, disabling wifi, using some minimalist distro etc.

You could perhaps post:

inxi -C
cpupower frequency-info
cat /sys/devices/system/cpu/cpu*/power/energy_perf_bias
cat /etc/default/cpupower

This might give forum members some more clues.

->  inxi -C
  Info: 12-core (4-mt/8-st) model: 12th Gen Intel Core i5-1240P bits: 64
    type: MST AMCP cache: L2: 26 MiB
  Speed (MHz): avg: 810 min/max: 400/4400:3300 cores: 1: 792 2: 1000 3: 882
    4: 514 5: 1000 6: 1000 7: 811 8: 1000 9: 679 10: 571 11: 698 12: 674 13: 661
    14: 1000 15: 684 16: 1000
->  cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.40 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 1000 MHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 869 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

I just set all perf_bias values to 10 for simplicity, since it didn’t do anything noticeable, even at extremes:

->  cat /sys/devices/system/cpu/cpu*/power/energy_perf_bias
->  cat /etc/default/cpupower
# Define CPUs governor
# valid governors: ondemand, performance, powersave, conservative, userspace.

# Limit frequency range
# Valid suffixes: Hz, kHz (default), MHz, GHz, THz

# Specific frequency to be set.
# Requires userspace governor to be available.
# Do not set governor field if you use this one.

# Utilizes cores in one processor package/socket first before processes are 
# scheduled to other processor packages/sockets.
# See man (1) CPUPOWER-SET for additional details.

# Utilizes thread siblings of one processor core first before processes are
# scheduled to other cores. See man (1) CPUPOWER-SET for additional details.

#  Sets a register on supported Intel processore which allows software to convey
# its policy for the relative importance of performance versus energy savings to
# the  processor. See man (1) CPUPOWER-SET for additional details.

# vim:set ts=2 sw=2 ft=sh et:
1 Like

The people on the Framework forum, unsurprisingly, want to pass the buck back to the OS. I wasn’t aware that Linux distros can have much control over power usage, beyond providing something like powerprofilesdaemon or TLP, but someone said this:

Distributions do a lot in tuning all the services around the kernel as well, and those potentially can influence power usage by a lot as well: time-outs on when to set components to lower power states, write-back intervals to disks (causing wake-ups), active-polling for events or checking status (waking up the CPU and possible other components). There must be a lot of compromises and choices in configuring those things and they might add up to significant differences. Since the tuning is so difficult, most distributions will probably use the “factory defaults” from upstream, so this is probably limited too, but for some daemons and services there are different upstreams to choose from, so then the difference can easily be big.

Does any of this seem relevant? Such tuning doesn’t seem like something that EndeavourOS would involve itself in. I do think the ultimate problem is probably something system-wide, because one or two misbehaving processes probably wouldn’t result in literally double the expected power consumption.

That I see similarly high power usage on every linux version I’ve tried on this computer makes me wonder: could this be some kind of hardware issue?

I think in case of Arch / :enos: it’s the lack of any tuning that plays a role, most distros do things…Arch / :enos: is default / DIY distro…