# \[TRACKING\] Linux battery life tuning

**URL:** <https://community.frame.work/t/tracking-linux-battery-life-tuning/6665>\
**Category:** Linux\
**Tags:** ubuntu, other-distro\
**Created:** [September 13, 2021, 6:38am UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665 "2021-09-13T06:38:48Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![TJ1](https://avatars.discourse-cdn.com/v4/letter/t/22d042/32.png) [@TJ1](https://community.frame.work/u/TJ1)\
**Post date:** [September 13, 2021, 6:38am UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/1 "2021-09-13T06:38:48Z")

</div>

# Ubuntu:

There is now an official guide for [Optimizing Ubuntu Battery Life](https://knowledgebase.frame.work/en_us/optimizing-ubuntu-battery-life-Sye_48Lg3) on the Framework Knowledgebase written by Linux Support Lead @Matt_Hartley! If you are using Ubuntu, that is the recommended course of action.

# For other distros:

There are many threads on linux battery life. I think we should probably have a wiki page with the relevant information. I’ve dug out some relevant bits from various threads.

## Tuning idle power usage

Install the [powertop](https://github.com/fenrus75/powertop) and [tlp](https://linrunner.de/tlp/).

The idle power usage can be tuned down to 2.5W by

> $ sudo powertop --auto-tune

This can be enabled as a one-shot on some distributions via systemd service file (via @IPGentlemann)

> $ sudo systemctl enable powertop

It is also necessary to configure /etc/tlp.conf with these settings:

> PCIE\_ASPM\_ON\_BAT=powersupersave

After setting these two items, on the lowest brightness idle you will see the CPU hit C8 states on the second tab of powertop and the overall usage be roughly 2.5W if you have a single DIMM. Without ASPM enabled, the power usage will be between 3-4W.

> **Note for Fedora users:** Fedora workstation comes with `power-profiles-daemon` by default. While simpler than tlp, it is less powerful, and directly conflicts with it. It is anecdotally recommended you disable PPD by running `tlp start` to see it’s recommendations for disabling. [tlp vs. power-profiles-daemon - Reddit](https://www.reddit.com/r/Fedora/comments/qpaa4g/tlp_vs_powerprofilesdaemon/)

From @Michael_Wu

> Stock, the CPU should be able to reach C8 state, with PSR off. With PSR on the CPU should reach C9/C10. (PSR works when the image on the screen is static, so not when a video is playing on screen, flashing notifications, etc.). [Battery Life? - #63 by Brett\_Kosinski](http://community.frame.work/t/battery-life/861/63)

From @technical27 ([[TRACKING] Linux battery life tuning - #156 by technical27](http://community.frame.work/t/tracking-linux-battery-life-tuning/6665/156))

> I was having trouble hitting PC10, but then I found out it works after a reboot/fresh boot but not after suspending. It always works during suspend, but after the first suspend, it no longer worked in normal use until the next power cycle. The fix, add `nvme.noacpi=1` to your kernel parameters.

## Suspend power usage

There are three major paths to improving suspend battery life:

1. Enable hibernation, which requires some involved setup, but results in behavior similar to Windows.
2. Use “deep” sleep instead of “s2idle”, which reduces suspend power draw at the tradeoff of longer time required to resume.
3. 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](https://linuxhint.com/change-grub-options/) for instructions on changing kernel parameters.

## Panel self-refresh (WIP)

On kernel \>= 5.14 (such as Fedora 35), the PSR disablement is no longer necessary. The enabled PSR helps to save battery life.

> [@Michael\_Wu](#):
>
> I believe newer kernels have PSR enabled by default. It can be force disabled by adding this kernel boot parameter `i915.enable_psr=0` and force enabled with `i915.enable_psr=1`
> 
> PSR status can be checked with:  
> `cat /sys/kernel/debug/dri/0/i915_edp_psr_status`

> [@Michael\_Wu](#):
>
> I’ve seen reports of it working pre Kernel 5.14.0 on not Fedora. Some fixes for Intel display drivers apparently made it into Kernel 5.14, and I’ve been running 5.14.0 vanilla on Fedora for the past week. Can confirm that PSR works like it should with no stuttering/micro-freezes, with the idle power savings and CPU reaching C9/C10. Had issues on 5.12.x and 5.13.x.

If PSR is enabled on pre-5.14 kernels, there may be stuttering. To remove PSR see [Periodic stuttering on fresh gnome.40 wayland install on Arch Linux - #6 by William\_Light](http://community.frame.work/t/periodic-stuttering-on-fresh-gnome-40-wayland-install-on-arch-linux/3912/6)

More references:

- [Improving Linux battery life, enabling PSR by default, testers wanted: hansdegoede — LiveJournal](https://hansdegoede.livejournal.com/18653.html)
- [Fedora Linux 35 (Fedora 35) on the Framework Laptop](http://community.frame.work/t/fedora-linux-35-on-the-framework-laptop/6613)

## Tuning disk usage (WIP)

- Set fstab options for disks to be noatime or relatime [From @Brett_Kosinski]

## Audio usage (WIP)

I’ve unscientifically noticed that pipewire appears to use less power than pulseaudio. The following 3 daemons need to be running for a drop-in replacement for pulseaudio.

> pipewire  
> pipewire-pulse  
> pipewire-media-session

## Expansion Card Power Usage (WIP)

HDMI and SD Card expansions appear to be using 1W whether or not they are in use. _There appears to be a fix with autosuspend or perhaps with a newer bios?_

## DRAM

Note that larger quantities and higher speeds (e.g. 3200 instead of 2666) of memory will result in higher active, idle, and suspend power consumption. There is a detailed study on this here: [[Battery Life] Impact of RAM / memory configuration + extra data](http://community.frame.work/t/battery-life-impact-of-ram-memory-configuration-extra-data/6426)

## Wifi (WIP)

### AX210

Note that the vPro version of AX210 (or other Intel WiFi modules) may have power management issues in Linux.

### Ath9k

Power management needs to be enabled as a kernel option. Old reports indicate that wifi power saving may cause drops on connectivity, but not sure if they still apply. This seems to save between 1.0-1.5W. The part number that was tested is Atheros QCNFA222 AR5BWB222 on Framework 13 Intel i5 i5-1135G7.

```auto
# Note that a reboot may be required to reload with the new kernel opt
$ cat /etc/modules.d/ath9k.conf
options ath9k ps_enable=1
$ cat /sys/module/ath9k/parameters/ps_enable
1
$ sudo iw dev wlp170s0 set power_save on
$ sudo iw dev wlp170s0 get power_save
Power save: on

```

## Kernel version

5.13 uses less power than 5.12 (approximately 0.5W)

## Video playback tuning (WIP)

## Full disk encryption (WIP)

I’ve unscientifically noticed that it is 3W rather than 2.5W idle.

## GPU rendering with Firefox and Chrome

- Install **`intel-media-driver`** and **`intel-gpu-tools`**

**FOR FIREFOX**

- Type in **`about:config`** in the address bar and hit enter.

- Set `media.rdd-ffmpeg.enabled,` `media.ffmpeg.vaapi.enabled` and `media.navigator.mediadatadecoder_vpx_enabled` to **true**.

**FOR CHROME/IUM**

- Enable these Flags under chrome://flags

> Temporarily unexpire M90 flags, override software rendering list, GPU rasterization, Hardware-accelerated video decode & Zero-copy rasterizer

- Go to your `~/.config directory` and make a `chrome-flags.conf` or `chromium-flags.conf` (whichever you use) file.
- Paste the following and save.

> REFER TO THIS [ARCH THREAD](https://bbs.archlinux.org/viewtopic.php?id=244031) ON THE CURRENT FLAGS NEEDED FOR CHROME / CHROMIUM.

**FOR VERIFYING GPU USAGE**

- Run the command `sudo intel_gpu_top`, play a 4k video and check whether the `Video` section is above 0.00%

More references:

- [Archwiki - Firefox](https://wiki.archlinux.org/title/Firefox#Hardware_video_acceleration)
- [Archwiki - Chromium](https://wiki.archlinux.org/title/Chromium#Hardware_video_acceleration)
- [Updated Guide on how to get hardware acceleration working on Chrome and chromium based browsers.](https://www.reddit.com/r/linux/comments/p2ivtq/updated_guide_on_how_to_get_hardware_acceleration/)

## Battery charge threshold

Available in BIOS

---

<div class="post-metadata">

**Author:** ![nrp](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/nrp/32/352_2.png) [@nrp](https://community.frame.work/u/nrp)\
**Post date:** [September 13, 2021, 3:43pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/2 "2021-09-13T15:43:30Z")

</div>

Awesome! Thanks for starting this. I just converted it into a wiki post.

---

<div class="post-metadata">

**Author:** ![Brett\_Kosinski](https://avatars.discourse-cdn.com/v4/letter/b/67e7ee/32.png) [@Brett\_Kosinski](https://community.frame.work/u/Brett_Kosinski)\
**Post date:** [September 13, 2021, 3:53pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/3 "2021-09-13T15:53:01Z")

</div>

> [@TJ1](#):
>
> Set fstab options for disks to be noatime

FYI, I believe the best practice advice is to use relatime rather than noatime, as the former is safer and the performance benefit is roughly the same.

It’s also worth checking to see if this is the default in your system. I just looked and my /home was mounted with relatime enabled without my doing anything.

Also, worth noting that “powertop --auto-tune” and TLP conflict with one another, so you should use one or the other. Given the success with TLP, my recommendation would be to just stick with that.

---

<div class="post-metadata">

**Author:** ![Michael\_Wu](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/michael_wu/32/18481_2.png) [@Michael\_Wu](https://community.frame.work/u/Michael_Wu)\
**Post date:** [September 13, 2021, 5:04pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/4 "2021-09-13T17:04:25Z")

</div>

Thanks for the compilation @TJ1 !

A few possible corrections (at least from my research):

> [@TJ1](#):
>
> After setting these two items, on the lowest brightness idle you will see the CPU hit C8 states on the second tab of powertop

Stock, the CPU should be able to reach C8 state, with PSR off. With PSR on the CPU should reach C9/C10. (PSR works when the image on the screen is static, so not when a video is playing on screen, flashing notifications, etc.).

> [@TJ1](#):
>
> It’s a thing, however, I’m not sure it works on linux.

I’ve seen reports of it working pre Kernel 5.14.0 on not Fedora. Some fixes for Intel display drivers apparently made it into Kernel 5.14, and I’ve been running 5.14.0 vanilla on Fedora for the past week. Can confirm that PSR works like it should with no stuttering/micro-freezes, with the idle power savings and CPU reaching C9/C10. Had issues on 5.12.x and 5.13.x.

---

<div class="post-metadata">

**Author:** ![TJ1](https://avatars.discourse-cdn.com/v4/letter/t/22d042/32.png) [@TJ1](https://community.frame.work/u/TJ1)\
**Post date:** [September 13, 2021, 5:08pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/5 "2021-09-13T17:08:34Z")

</div>

> [@Michael\_Wu](#):
>
> Can confirm that PSR works like it should with no stuttering/micro-freezes, with the idle power savings and CPU reaching C9/C10. Had issues on 5.12.x and 5.13.x.

Oh cool, how do you enable it? Is it a compile time option for 5.14 or something that needs to be done with sysctl?

> [@Michael\_Wu](#):
>
> Stock, the CPU should be able to reach C8 state, with PSR off. With PSR on the CPU should reach C9/C10. (PSR works when the image on the screen is static, so not when a video is playing on screen, flashing notifications, etc.).

Updating wiki. I can also confirm without PSR it only reaches C8.

---

<div class="post-metadata">

**Author:** ![TJ1](https://avatars.discourse-cdn.com/v4/letter/t/22d042/32.png) [@TJ1](https://community.frame.work/u/TJ1)\
**Post date:** [September 13, 2021, 5:18pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/6 "2021-09-13T17:18:00Z")

</div>

> [@Brett\_Kosinski](#):
>
> FYI, I believe the best practice advice is to use relatime rather than noatime, as the former is safer and the performance benefit is roughly the same.

Thanks, updated.

> [@Brett\_Kosinski](#):
>
> Also, worth noting that “powertop --auto-tune” and TLP conflict with one another, so you should use one or the other. Given the success with TLP, my recommendation would be to just stick with that.

Hmmm…do you have more details on where they conflict / overlap? I suppose it should be the autosuspend settings? Is the equivalent of what powertop does the setting

> USB\_AUTOSUSPEND=1

---

<div class="post-metadata">

**Author:** ![Michael\_Wu](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/michael_wu/32/18481_2.png) [@Michael\_Wu](https://community.frame.work/u/Michael_Wu)\
**Post date:** [September 13, 2021, 5:19pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/7 "2021-09-13T17:19:30Z")

</div>

> [@TJ1](#):
>
> Oh cool, how do you enable it? Is it a compile time option for 5.14 or something that needs to be done with sysctl?

I believe newer kernels have PSR enabled by default. It can be force disabled by adding this kernel boot parameter `i915.enable_psr=0` and force enabled with `i915.enable_psr=1`

PSR status can be checked with:  
`cat /sys/kernel/debug/dri/0/i915_edp_psr_status`

Extra info:

> **[Improving Linux battery life, enabling PSR by default, testers wanted](https://hansdegoede.livejournal.com/18653.html)**
>
> Hi All, Update: Thank you everyone for all the test-reports Ive received. The response has been quite overwhelming, with over 50 test-reports received sofar. The results are all over the place, some people see no changes, some people report the...

Sidenote, just read this thread on Fedora 35 that confirms PSR works out of the box:

> [@Fedora Linux 35 (Fedora 35) on the Framework Laptop](http://community.frame.work/t/fedora-linux-35-on-the-framework-laptop/6613):
>
> Fedora 35 is now released and has effectively full support out of the box for the Framework Laptop. Installation A detailed step-by-step guide is available [here](https://guides.frame.work/Guide/Fedora+35+Installation+on+the+Framework+Laptop/108). Short instructions are below. Create Fedora 35 USB installer or Live USB drive using the [Fedora Media Writer](https://getfedora.org/en/workstation/download/) Insert the created USB drive into your Framework Laptop If there is a bootable OS already installed on your internal drive, tap F12 repeatedly while booting to bring up the boot selection menu, and select the USB drive. Try …

---

<div class="post-metadata">

**Author:** ![Brett\_Kosinski](https://avatars.discourse-cdn.com/v4/letter/b/67e7ee/32.png) [@Brett\_Kosinski](https://community.frame.work/u/Brett_Kosinski)\
**Post date:** [September 13, 2021, 6:01pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/8 "2021-09-13T18:01:09Z")

</div>

> [@TJ1](#):
>
> Hmmm…do you have more details on where they conflict / overlap? I suppose it should be the autosuspend settings?

There’s a ton of overlap. Both powertop and TLP touch a lot of different settings, including various power management and auto-suspend settings for a whole host of devices, kernel parameter changes (e.g. VM writeback timeout), and so forth.

---

<div class="post-metadata">

**Author:** ![gjason](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/gjason/32/769_2.png) [@gjason](https://community.frame.work/u/gjason)\
**Post date:** [September 13, 2021, 6:34pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/9 "2021-09-13T18:34:21Z")

</div>

@TJ1 - regarding PowerTOP / TLP overlap, here’s what the TLP Devs say:

[https://linrunner.de/tlp/faq/powertop.html](https://linrunner.de/tlp/faq/powertop.html)

**TL;DR Summary:** Using PowerTOP to monitor usage alongside TLP is fine, but running `powertop --auto-tune` when TLP is running is effectively useless, as any changes that PowerTOP makes will be overwritten by TLP.

---

<div class="post-metadata">

**Author:** ![TJ1](https://avatars.discourse-cdn.com/v4/letter/t/22d042/32.png) [@TJ1](https://community.frame.work/u/TJ1)\
**Post date:** [September 13, 2021, 6:35pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/10 "2021-09-13T18:35:44Z")

</div>

Can you paste the /etc/tlp.conf that gets you to 2.5W?

---

<div class="post-metadata">

**Author:** ![gjason](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/gjason/32/769_2.png) [@gjason](https://community.frame.work/u/gjason)\
**Post date:** [September 13, 2021, 6:43pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/11 "2021-09-13T18:43:27Z")

</div>

One more point on TLP conflicts: [it doesn’t play well with power-profiles-daemon](https://linrunner.de/tlp/faq/installation.html#does-tlp-conflict-with-other-power-management-tools), which is [installed & enabled by default in Fedora Linux 35](https://fedoraproject.org/wiki/Changes/Power_Profiles_Daemon).

---

<div class="post-metadata">

**Author:** ![Brett\_Kosinski](https://avatars.discourse-cdn.com/v4/letter/b/67e7ee/32.png) [@Brett\_Kosinski](https://community.frame.work/u/Brett_Kosinski)\
**Post date:** [September 13, 2021, 6:52pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/12 "2021-09-13T18:52:14Z")

</div>

> [@TJ1](#):
>
> Can you paste the /etc/tlp.conf that gets you to 2.5W?

Not quite what you’re looking for but here’s a dump of tlp-stat on my system which shows the full config:

[https://blog.b-ark.ca/assets/files/framework-tlp-stat.txt](https://blog.b-ark.ca/assets/files/framework-tlp-stat.txt)

---

<div class="post-metadata">

**Author:** ![TJ1](https://avatars.discourse-cdn.com/v4/letter/t/22d042/32.png) [@TJ1](https://community.frame.work/u/TJ1)\
**Post date:** [September 13, 2021, 6:59pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/13 "2021-09-13T18:59:09Z")

</div>

> [@gjason](#):
>
> One more point on TLP conflicts: [it doesn’t play well with power-profiles-daemon](https://linrunner.de/tlp/faq/installation.html#does-tlp-conflict-with-other-power-management-tools), which is [installed & enabled by default in Fedora Linux 35](https://fedoraproject.org/wiki/Changes/Power_Profiles_Daemon).

Hmmmm…ok. So it appears we need a section for TLP and a section for the power-profiles-daemon. Recommendations?

> [@Brett\_Kosinski](#):
>
> Not quite what you’re looking for but here’s a dump of tlp-stat on my system which shows the full config:
> 
> [https://blog.b-ark.ca/assets/files/framework-tlp-stat.txt](https://blog.b-ark.ca/assets/files/framework-tlp-stat.txt)

On my TLP configuration, for some reason I have two USB devices that are not using autosuspend which is why I ran powertop --auto-tune to start. Goodix and an unidentified one. Are they tuned correctly with your configuration? I just don’t see the relevant difference between the two configs:

```auto
TLP_ENABLE=1
TLP_DEFAULT_MODE=AC
DISK_IDLE_SECS_ON_AC=0
DISK_IDLE_SECS_ON_BAT=2
MAX_LOST_WORK_SECS_ON_AC=15
MAX_LOST_WORK_SECS_ON_BAT=60
CPU_BOOST_ON_AC=1
SCHED_POWERSAVE_ON_AC=0
SCHED_POWERSAVE_ON_BAT=1
NMI_WATCHDOG=0
ENERGY_PERF_POLICY_ON_AC=performance
ENERGY_PERF_POLICY_ON_BAT=powersave
DISKS_DEVICES="nvme0"
DISK_APM_LEVEL_ON_AC="254 254"
DISK_APM_LEVEL_ON_BAT="128 128"
SATA_LINKPWR_ON_AC=max_performance
SATA_LINKPWR_ON_BAT=min_power
AHCI_RUNTIME_PM_TIMEOUT=15
PCIE_ASPM_ON_AC=performance
PCIE_ASPM_ON_BAT=powersupersave
RADEON_POWER_PROFILE_ON_AC=high
RADEON_POWER_PROFILE_ON_BAT=low
RADEON_DPM_STATE_ON_AC=performance
RADEON_DPM_STATE_ON_BAT=battery
RADEON_DPM_PERF_LEVEL_ON_AC=auto
RADEON_DPM_PERF_LEVEL_ON_BAT=auto
WIFI_PWR_ON_AC=off
WIFI_PWR_ON_BAT=on
WOL_DISABLE=Y
SOUND_POWER_SAVE_ON_AC=0
SOUND_POWER_SAVE_ON_BAT=1
SOUND_POWER_SAVE_CONTROLLER=Y
BAY_POWEROFF_ON_BAT=0
BAY_DEVICE=sr0
RUNTIME_PM_ON_AC=on
RUNTIME_PM_ON_BAT=auto
RUNTIME_PM_ALL=1
RUNTIME_PM_DRIVER_BLACKLIST="radeon nouveau"
USB_AUTOSUSPEND=1
USB_BLACKLIST_WWAN=1
RESTORE_DEVICE_STATE_ON_STARTUP=0

```

---

<div class="post-metadata">

**Author:** ![Brett\_Kosinski](https://avatars.discourse-cdn.com/v4/letter/b/67e7ee/32.png) [@Brett\_Kosinski](https://community.frame.work/u/Brett_Kosinski)\
**Post date:** [September 13, 2021, 7:26pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/14 "2021-09-13T19:26:19Z")

</div>

> [@TJ1](#):
>
> On my TLP configuration, for some reason I have two USB devices that are not using autosuspend which is why I ran powertop --auto-tune to start. Goodix and an unidentified one. Are they tuned correctly with your configuration?

So here’s something weird: Initially, autosuspend was enabled:

 ![image](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/2X/5/54b8df779d4a15307721db3c7988c15de22daea8.png)

(this is using TLP to apply power management settings, but powertop for reporting on status of tunables)

However, a short time later, after a USB device reset on the fingerprint reader, autosuspend was no longer enabled.

I then manually re-enabled autosuspend, and have since had two more resets, but this time the autosuspend setting stuck.

I’ll see if I can replicate the circumstances for triggering the issue, but there’s definitely something going on here.

Now, note, aside from TLP, there’s also an intersection with udev. libfprint installs files to /lib/udev/hwdb.d and /lib/udev/rules.d (or, at least, those are the paths on my system) that contain device autosuspend rules and so forth. So I wonder if this behaviour indicates a bug in the libfprint goodixmoc driver or the udev configuration.

---

<div class="post-metadata">

**Author:** ![Tyler\_S](https://avatars.discourse-cdn.com/v4/letter/t/dc4da7/32.png) [@Tyler\_S](https://community.frame.work/u/Tyler_S)\
**Post date:** [September 13, 2021, 8:25pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/15 "2021-09-13T20:25:06Z")

</div>

Does anybody have any recommendations to enable c-states greater than C1, I am using an arch based distro called Garuda running on kernel 5.14.

Thanks

---

<div class="post-metadata">

**Author:** ![Brett\_Kosinski](https://avatars.discourse-cdn.com/v4/letter/b/67e7ee/32.png) [@Brett\_Kosinski](https://community.frame.work/u/Brett_Kosinski)\
**Post date:** [September 13, 2021, 8:39pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/16 "2021-09-13T20:39:43Z")

</div>

> [@Tyler\_S](#):
>
> Does anybody have any recommendations to enable c-states greater than C1, I am using an arch based distro called Garuda running on kernel 5.14.

Heh, that’s exactly what @TJ1 's initial post covers! Using the configuration outlined above, with PSR enabled, my machine regularly idles in C10.

---

<div class="post-metadata">

**Author:** ![darthdomo](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/darthdomo/32/1172_2.png) [@darthdomo](https://community.frame.work/u/darthdomo)\
**Post date:** [September 13, 2021, 9:43pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/17 "2021-09-13T21:43:35Z")

</div>

I’ve done the tweaks mentioned above, but I’m still having very bad standby life in Arch. In ~10 hours of standby, the battery dropped by 26%.

I’ve tried using powertop to analyze what happened, but to be honest I don’t understand a lot of the output (mainly pertaining to sleep data).

Anyone have any ideas? I’d appreciate any help, it’s the only thing I don’t like about the laptop atm. My battery life during use is perfectly fine.

---

<div class="post-metadata">

**Author:** ![Anthony\_Bucci](https://avatars.discourse-cdn.com/v4/letter/a/3e96dc/32.png) [@Anthony\_Bucci](https://community.frame.work/u/Anthony_Bucci)\
**Post date:** [September 13, 2021, 10:01pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/18 "2021-09-13T22:01:47Z")

</div>

Have you tried using s3 sleep instead of s0ix? It’ll take longer to wake but should get you better drain rates.

---

<div class="post-metadata">

**Author:** ![nrp](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/nrp/32/352_2.png) [@nrp](https://community.frame.work/u/nrp)\
**Post date:** [September 13, 2021, 10:02pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/19 "2021-09-13T22:02:30Z")

</div>

One other thought/question in general for folks seeing high standby drain on Linux:

1. Do you have an HDMI or DisplayPort Expansion Card plugged in?
2. Do you have the vPro version of the AX210?

---

<div class="post-metadata">

**Author:** ![darthdomo](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/darthdomo/32/1172_2.png) [@darthdomo](https://community.frame.work/u/darthdomo)\
**Post date:** [September 13, 2021, 10:05pm UTC](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/20 "2021-09-13T22:05:07Z")

</div>

@nrp ~~Nope for me on both accounts. I’m only using USB-C and USB-A cards~~ (see edit), and I’ve got the non-vPro version of the AX210.

I’m curious if it might be an issue with my kernel version. I ended up having to downgrade to 5.12.15, due to issues with bluetooth on the AX210 with any of the 5.13 kernels I’ve tried.

EDIT: I’m dumb. I swapped in an HDMI card late last night, to demo to a friend. I completely forgot to take it back out. That’s likely a large reason for my bad drain.

[Next page](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665.md?page=2)
