I am debian user since about August last year(2022), and a "linux" user since about feburary last year, but i am still fairly new (noob) and feel free to corect me for any of my mistakes, and I beg your pardon in advance for my poor spellings (or grammar)
I have experienced increased power usage in my device (an HP laptop notebook, from june 2022, Intel 11th gen i3, using kernel drivers + nonfree wifi drivers, no discrete gpu, only an igpu, the laptop seems to be well supported no other major issues with compatibility) when i upgrade my kernel (currently using bullseye's 5.10.0-22) to a newer kernel (from many sources, have used Arch kernels 5.18.x and 5.19.x, fedora's 5.18.x kernels, void's 5.19.x kernels, debian bullseye-backports 5.18.x and 5.19.x kernels, and all debian testing kernels since then), so possibly this is an upstream issue, which may be well documented but i have not found much on this, most i have found is mixed experiences, where only 1 comes closest to my problems though it did not fix the issue https://forums.linuxmint.com/viewtopic. ... 9&t=392090
Main issue i have identified is that somehow the CPU governor is not working well, i use tlp for improving battery performance, and since about december 22, i have been usually getting an idle power draw of 2.2-3 watts, i use powersave governor, and using intel_pstate drivers, with this, my idle cpu freq is within 900-1200 Mhz, and system goes into deeper c states (C6, C8), with newer kernels, either the cpu scaling does not take place correctly (gets stuck to or very frequently jumping back to 2000Mhz, or if change the parameter(active/passive) as mentioned in the linked post above, it gets stuck to 400 Mhz (but this also decreases the power usage to about 4.3w)(the minimum my cpu can handle), and does not go into deeper c states beyond C3
Power draw is measured via upowerd(more accurate) and powertop, frequencies as reported by htop, and cstates as reported by powertop (i do not have a powertop daemon running)
Since idle cpu scaling does not occur, this also reflects the increased power draw, in load (like video playback(mpv, yt-dlp) at 360p in a 1920x1080 screen using 4.5w vs 6.5w). Recently i performed a bios update which made battery life better with seemingly all kernels, 5.10 now goes to 1.9w for increased durations, whereas it rarely went below 2w earlier whereas on newer kernels, now changuing parameter(active/passive) no longer has any effect and i see 4.2w usage, but the cpu scaling is still stuck as noted above. I have tried other fixes (ike trying acpi drivers, forcing lower clock speeds, and some others) but to no avail, i seek for help, if result of some command is required, kindly just post a reply to this post, i am attaching my tlp config file (i have bluetooth disabled, and also removed its drivers(non free), i got increased power usage if i left them).
Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
- Attachments
-
- tlp.conf.tar.gz
- (5.07 KiB) Downloaded 36 times
Last edited by sga on 2023-06-20 20:14, edited 1 time in total.
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
i forgot to mention, but i have been using testing since january 23, and unless i upgrade my kernel, it had no major impact on power draw (marginally reduced by maybe about 0.1 w on idle)
I am using a very non standard lxqt environment, and system as of today is almost exclusively bookworm stable only (other than kernel)
I am using a very non standard lxqt environment, and system as of today is almost exclusively bookworm stable only (other than kernel)
Last edited by sga on 2023-06-15 11:51, edited 1 time in total.
-
Aki
- Global Moderator
- Posts: 4149
- Joined: 2014-07-20 18:12
- Location: Europe
- Has thanked: 119 times
- Been thanked: 556 times
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
Hello,
Why don't you compare the power consumption at idle of kernel 6.1 (shipped with Debian Bookworm) with your previously installed kernels ?
Can you post the command you use to measure power consumption ?
Why don't you compare the power consumption at idle of kernel 6.1 (shipped with Debian Bookworm) with your previously installed kernels ?
Can you post the command you use to measure power consumption ?
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
I have also tested with the 6.1 kernel (when it was in testing, and now when it is in stable), same behaviour as other newer kernels
i am using upower -d | grep energy-rate ( well i dont exactly use this one, i use a variant with the specificid of my baatery but it is effectively same, use this(upower -e) to get the ids and then use upower -i <id>), as far as i know, this method is just using the data as using /sys/class..... path for battery related stuff (for me /sys/class/power_supply/BAT0), and manually doing calculations, the difference is actually quiet big, as even writing right now the power draw is 2.8~3.8 watts, where as doing same(ish) operation on newer kernels takes about 4.8~5.6 watts
(for getting a reading for a longer duration for accuracy, you can check the history rate section in output of upower -i <id> (at the end)
like for me
1686714963 3.844 discharging
1686714933 3.617 discharging
1686714903 4.003 discharging
1686714873 3.436 discharging)
i am using upower -d | grep energy-rate ( well i dont exactly use this one, i use a variant with the specificid of my baatery but it is effectively same, use this(upower -e) to get the ids and then use upower -i <id>), as far as i know, this method is just using the data as using /sys/class..... path for battery related stuff (for me /sys/class/power_supply/BAT0), and manually doing calculations, the difference is actually quiet big, as even writing right now the power draw is 2.8~3.8 watts, where as doing same(ish) operation on newer kernels takes about 4.8~5.6 watts
(for getting a reading for a longer duration for accuracy, you can check the history rate section in output of upower -i <id> (at the end)
like for me
1686714963 3.844 discharging
1686714933 3.617 discharging
1686714903 4.003 discharging
1686714873 3.436 discharging)
-
Aki
- Global Moderator
- Posts: 4149
- Joined: 2014-07-20 18:12
- Location: Europe
- Has thanked: 119 times
- Been thanked: 556 times
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
Programs running in user space could be a confounding factor.
The power drain reported by upowerd is an overall measure and does not indicate which software/hardware component is draining power.
Have you measured the power consumption when starting the computer as a single user or multi-user (no graphics) with both older and newer kernels ?
It would be interesting collect data using powerstat with both kernels (old and new)
The power drain reported by upowerd is an overall measure and does not indicate which software/hardware component is draining power.
Have you measured the power consumption when starting the computer as a single user or multi-user (no graphics) with both older and newer kernels ?
It would be interesting collect data using powerstat with both kernels (old and new)
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
Booting into graphics(by adding kernel parameter 3), almost same power draw as that with graphics (1.973w vs 3.287w (best foot forward)), all other things are kept same (same daemons, same autostarts)(adding htop pictures from different boots(on a sidenote, how to save output of htop in aclearly formated text file, or take a screenshot in tty)), my claim is that it is the cpu governor being broken (or it previously being broken and now implemented differently), 1 thing powertop can do is guess the power usage (it is not as accurate as a real reading according to online sources),the differnce between these 2 outputs that i can see is usage of cpu core and cpu misc, and obviously the discharge rate, I would also request anyone to help find a more scientific methodology to measure power breakdown (other than breaking open the laptop and hooking multimeters everywhere)
old kernel
new kernel
powerstat -a 5 60
old kernel
new kernel
Code: Select all
The battery reports a discharge rate of 2.12 W
The energy consumed was 51.2 J
Usage Device name
0.8 pkts/s Network interface: wlo1 (rtw_8822ce)
0.0% Display backlight
4.0% CPU core
4.0% CPU misc
100.0% Radio device: rtw_8822ce
0.0% Audio codec hwC0D0: Realtek
0.0% Radio device: btusb
100.0% PCI Device: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant
100.0% PCI Device: Intel Corporation Tiger Lake-LP PCI Express Root Port #8
100.0% PCI Device: Intel Corporation Tiger Lake-LP PCI Express Root Port #9
100.0% PCI Device: Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac PCIe Wireless Network Adapter
100.0% PCI Device: Intel Corporation Tiger Lake-LP GT2 [UHD Graphics G4]
100.0% PCI Device: Intel Corporation Volume Management Device NVMe RAID Controller
100.0% PCI Device: Micron Technology Inc Device 5411
0.0% PCI Device: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1
0.0% runtime-i2c_designware.1
0.0% PCI Device: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller
0.0% runtime-skl_hda_dsp_generic
0.0% USB device: HP TrueVision HD Camera (Chicony Electronics Co.,Ltd.)
0.0% USB device: Bluetooth Radio (Realtek)
0.0% USB device: xHCI Host Controller
0.0% Audio codec hwC0D2: Intel
0.0% PCI Device: Intel Corporation GNA Scoring Accelerator module
0.0% runtime-INTC1043:00
0.0% runtime-INT34C5:00
0.0% runtime-ACPI0003:00
0.0% runtime-PNP0C14:00
0.0% PCI Device: Intel Corporation Device 9a04
0.0% PCI Device: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0
0.0% PCI Device: Intel Corporation RST VMD Managed Controller
0.0% PCI Device: Intel Corporation Tiger Lake-LP Shared SRAM
0.0% PCI Device: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller
0.0% PCI Device: Intel Corporation Tiger Lake-LP SMBus Controller
0.0% PCI Device: Intel Corporation Tiger Lake-LP LPC Controller
0.0% PCI Device: Intel Corporation Tiger Lake-LP Management Engine Interface
0.0% PCI Device: Intel Corporation Tiger Lake-LP SPI Controller
0.0% runtime-INTC1040:00
0.0% runtime-alarmtimer.0.auto
0.0% runtime-reg-dummy
0.0% runtime-iTCO_wdt
0.0% runtime-PNP0C0D:00
0.0% runtime-PNP0C09:00
0.0% I2C Adapter (i2c-13): AUX D/port D
0.0% USB device: xHCI Host Controller
0.0% runtime-INT33A1:00
0.0% runtime-microcode
0.0% runtime-snd-soc-dummy
0.0% runtime-INTC1045:00
0.0% runtime-intel_rapl_msr.0
0.0% runtime-HPQ6001:00
0.0% runtime-PNP0C0A:00
0.0% runtime-PNP0C0C:00
0.0% runtime-idma64.1
Code: Select all
The battery reports a discharge rate of 3.44 W
The energy consumed was 74.9 J
Usage Device name
0.0% Display backlight
0.8 pkts/s Network interface: wlo1 (rtw_8822ce)
6.8% CPU core
6.8% CPU misc
100.0% Radio device: rtw_8822ce
0.0% Audio codec hwC0D0: Realtek
0.0% Radio device: btusb
100.0% PCI Device: Intel Corporation Tiger Lake-LP GT2 [UHD Graphics G4]
100.0% PCI Device: Intel Corporation Volume Management Device NVMe RAID Controller
100.0% PCI Device: Micron Technology Inc Device 5411
100.0% PCI Device: Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac PCIe Wireless Network Adapter
100.0% PCI Device: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant
100.0% PCI Device: Intel Corporation Tiger Lake-LP PCI Express Root Port #9
100.0% PCI Device: Intel Corporation Tiger Lake-LP PCI Express Root Port #8
0.0% runtime-i2c_designware.1
0.0% PCI Device: Intel Corporation Device 9a04
0.0% PCI Device: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller
0.0% PCI Device: Intel Corporation RST VMD Managed Controller
0.0% PCI Device: Intel Corporation Tiger Lake-LP Shared SRAM
0.0% runtime-microcode
0.0% runtime-INTC1043:00
0.0% runtime-PNP0C14:00
0.0% PCI Device: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0
0.0% USB device: HP TrueVision HD Camera (Chicony Electronics Co.,Ltd.)
0.0% USB device: xHCI Host Controller
0.0% I2C Adapter (i2c-16): AUX USBC4/DDI TC4/PHY TC4
0.0% runtime-INT33A1:00
0.0% PCI Device: Intel Corporation Tiger Lake-LP LPC Controller
0.0% runtime-ACPI0003:00
0.0% runtime-reg-dummy
0.0% runtime-alarmtimer.0.auto
0.0% runtime-snd-soc-dummy
0.0% I2C Device (i2c-ELAN0712:00): ELAN0712:00
0.0% I2C Adapter (i2c-15): AUX USBC3/DDI TC3/PHY TC3
0.0% runtime-iTCO_wdt
0.0% runtime-PNP0C0D:00
0.0% runtime-PNP0C09:00
0.0% runtime-PNP0C0A:00
0.0% runtime-PNP0C0C:00
0.0% runtime-PNP0103:00
0.0% runtime-INTC1040:00
0.0% PCI Device: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1
0.0% I2C Adapter (i2c-0): SMBus I801 adapter at efa0
0.0% runtime-INTC1045:00
0.0% runtime-intel_rapl_msr.0
0.0% runtime-HPQ6001:00
0.0% runtime-skl_hda_dsp_generic
0.0% USB device: xHCI Host Controller
0.0% USB device: Bluetooth Radio (Realtek)
0.0% I2C Adapter (i2c-13): AUX USBC1/DDI TC1/PHY TC1
0.0% I2C Adapter (i2c-2): Synopsys DesignWare I2C adapter
0.0% I2C Adapter (i2c-5): i915 gmbus dpc
0.0% runtime-i2c_designware.0
old kernel
Code: Select all
Time User Nice Sys Idle IO Run Ctxt/s IRQ/s Watts x86_pk INT340 TCPU acpitz SEN1 CPU Freq Freq Min Freq Max
17:04:07 1.3 0.0 0.9 97.7 0.0 1 2536 770 3.13 42.00 20.00 42.00 44.00 42.05 1.03 GHz 0.94 GH 1.44 GHz z 1.17 GHz
17:04:12 3.7 0.0 1.3 94.9 0.1 1 5721 2042 5.08 43.00 20.00 41.00 44.00 42.05 0.87 GHz 0.53 GHz 1.03 GHz
17:04:17 1.4 0.1 2.7 95.8 0.0 1 3409 679 3.40 43.00 20.00 41.00 44.00 42.05 0.86 GHz 0.47 GHz 1.00 GHz
17:04:22 0.8 0.0 0.7 98.6 0.0 1 2167 512 2.98 42.00 20.00 41.00 44.00 43.05 0.93 GHz 0.84 GHz 1.04 GHz
17:04:27 0.6 0.0 0.5 98.9 0.0 1 2177 499 3.03 42.00 20.00 42.00 44.00 42.05 0.94 GHz 0.86 GHz 1.09 GHz
17:04:32 0.5 0.0 0.5 98.9 0.2 1 2125 501 3.13 42.00 20.00 41.00 44.00 42.05 0.94 GHz 0.86 GHz 1.03 GHz
17:04:37 0.5 0.1 2.4 97.0 0.0 1 3222 647 4.92 43.00 20.00 41.00 44.00 42.05 0.90 GHz 0.67 GHz 1.04 GHz
17:04:42 1.1 0.0 0.7 98.1 0.1 1 2343 648 3.72 42.00 20.00 40.00 44.00 42.05 0.95 GHz 0.88 GHz 1.03 GHz
17:04:47 1.0 0.0 0.6 98.4 0.0 1 2153 523 3.04 42.00 20.00 40.00 44.00 42.05 0.90 GHz 0.77 GHz 0.96 GHz
17:04:52 0.8 0.0 0.5 98.7 0.0 1 2162 522 3.22 42.00 20.00 41.00 44.00 42.05 0.92 GHz 0.81 GHz 1.01 GHz
17:04:57 1.2 0.2 2.5 96.2 0.0 1 3243 644 3.19 42.00 20.00 41.00 44.00 42.05 0.82 GHz 0.40 GHz 1.02 GHz
17:05:02 0.8 0.0 0.8 98.4 0.0 1 2160 552 3.54 42.00 20.00 41.00 44.00 42.05 0.88 GHz 0.71 GHz 1.04 GHz
17:05:07 0.7 0.0 0.6 98.7 0.0 1 2121 507 3.05 42.00 20.00 41.00 44.00 42.05 0.87 GHz 0.72 GHz 1.00 GHz
17:05:12 0.8 0.0 0.5 98.7 0.0 1 2242 574 3.05 42.00 20.00 41.00 44.00 42.05 0.96 GHz 0.82 GHz 1.08 GHz
17:05:17 0.6 0.0 0.5 98.9 0.1 1 2288 568 3.52 42.00 20.00 41.00 44.00 42.05 0.91 GHz 0.80 GHz 1.01 GHz
17:05:22 0.7 0.1 2.6 96.7 0.0 1 3255 668 4.20 42.00 20.00 41.00 44.00 42.05 0.84 GHz 0.67 GHz 0.98 GHz
17:05:27 0.3 0.0 0.6 99.1 0.0 1 2148 522 3.05 42.00 20.00 41.00 44.00 42.05 0.89 GHz 0.84 GHz 0.99 GHz
17:05:32 0.8 0.0 0.7 98.5 0.1 1 2161 547 3.41 42.00 20.00 41.00 44.00 42.05 0.86 GHz 0.56 GHz 1.00 GHz
17:05:37 0.9 0.0 0.6 98.5 0.0 1 2234 565 3.13 42.00 20.00 41.00 44.00 42.05 0.86 GHz 0.53 GHz 1.09 GHz
17:05:42 0.9 0.1 2.7 96.1 0.2 1 3331 672 3.27 42.00 20.00 40.00 44.00 42.05 0.89 GHz 0.76 GHz 1.02 GHz
17:05:47 1.2 0.0 0.5 98.2 0.1 1 2124 522 3.35 42.00 20.00 40.00 44.00 42.05 0.86 GHz 0.46 GHz 1.01 GHz
^C-------- ----- ----- ----- ----- ----- ---- ------ ------ ------ ------ ------ ------ ------ ------ ---------
Average 1.0 0.0 1.1 97.9 0.0 1.0 2634.4 651.6 3.45 42.14 20.00 40.90 44.00 42.10 0.90 GHz 0.71 GHz 1.03 GHz
GeoMean 0.8 0.0 0.9 97.9 0.0 1.0 2539.9 613.3 3.41 42.14 20.00 40.90 44.00 42.10 0.90 GHz 0.69 GHz 1.03 GHz
StdDev 0.7 0.0 0.8 1.2 0.1 0.0 833.6 319.6 0.58 0.35 0.00 0.53 0.00 0.21 0.05 GHz 0.15 GHz 0.05 GHz
-------- ----- ----- ----- ----- ----- ---- ------ ------ ------ ------ ------ ------ ------ ------ ---------
Minimum 0.3 0.0 0.5 94.9 0.0 1.0 2121.2 498.6 2.98 42.00 20.00 40.00 44.00 42.05 0.82 GHz 0.40 GHz 0.96 GHz
Maximum 3.7 0.2 2.7 99.1 0.2 1.0 5720.8 2042.4 5.08 43.00 20.00 42.00 44.00 43.05 1.03 GHz 0.94 GHz 1.17 GHz
-------- ----- ----- ----- ----- ----- ---- ------ ------ ------ ------ ------ ------ ------ ------ ---------
Summary:
System: 3.45 Watts on average with standard deviation 0.58
C-State Resident Count Latency
C3_ACPI 88.522% 105819 1048
C2_ACPI 7.815% 35805 253
C1_ACPI 1.089% 24646 1
POLL 0.000% 98 0
C0 2.575%
Histogram (of 21 power measurements)
Range (Watts) Count
2.982 - 3.191 10 ########################################
3.192 - 3.401 3 ############
3.402 - 3.610 4 ################
3.611 - 3.820 1 ####
3.821 - 4.030 0
4.031 - 4.240 1 ####
4.241 - 4.450 0
4.451 - 4.659 0
4.660 - 4.869 0
4.870 - 5.079 2 ########
Histogram (of 21 CPU utilization measurements)
Range (%CPU) Count
0.882 - 1.305 6 ########################################
1.306 - 1.728 6 ########################################
1.729 - 2.152 2 #############
2.153 - 2.575 1 ######
2.576 - 2.999 0
3.000 - 3.422 2 ######Code: Select all
Time User Nice Sys Idle IO Run Ctxt/s IRQ/s Watts x86_pk SEN1 TCPU acpitz INT340 CPU Freq Freq Min Freq Max
17:15:33 0.6 0.1 1.7 97.7 0.0 1 2202 531 4.39 40.00 42.05 39.00 44.00 20.00 1.38 GHz 0.73 GHz 2.00 GHz
17:15:38 0.5 0.0 0.1 99.2 0.2 1 1745 426 4.86 42.00 42.05 40.00 44.00 20.00 1.48 GHz 0.83 GHz 2.00 GHz
17:15:43 0.7 0.0 0.1 99.2 0.0 1 1822 438 4.41 40.00 42.05 39.00 44.00 20.00 1.49 GHz 0.81 GHz 2.00 GHz
17:15:48 0.8 0.0 0.3 98.7 0.2 1 1737 436 4.50 40.00 42.05 39.00 44.00 20.00 1.46 GHz 0.70 GHz 2.00 GHz
17:15:53 0.9 0.2 2.4 96.6 0.0 1 2400 573 4.32 41.00 42.05 39.00 44.00 20.00 1.51 GHz 0.89 GHz 2.00 GHz
17:15:58 0.6 0.0 0.4 99.0 0.0 1 1739 428 4.37 42.00 42.05 39.00 44.00 20.00 1.48 GHz 0.81 GHz 2.00 GHz
17:16:03 0.8 0.0 0.5 98.5 0.3 1 1825 487 4.64 42.00 42.05 39.00 44.00 20.00 1.43 GHz 0.98 GHz 2.00 GHz
17:16:08 0.7 0.0 0.6 98.5 0.2 1 1795 478 4.74 42.00 42.05 39.00 44.00 20.00 1.48 GHz 0.82 GHz 2.00 GHz
17:16:13 0.7 0.1 2.8 96.3 0.0 1 2394 592 4.37 42.00 42.05 39.00 44.00 20.00 1.49 GHz 0.80 GHz 2.00 GHz
17:16:18 0.8 0.0 0.7 98.5 0.0 1 1745 439 4.38 40.00 42.05 39.00 44.00 20.00 1.51 GHz 0.83 GHz 2.00 GHz
17:16:23 0.9 0.0 0.5 98.4 0.2 1 1765 440 4.69 40.00 42.05 39.00 44.00 20.00 1.54 GHz 0.91 GHz 2.00 GHz
17:16:28 0.5 0.0 0.3 99.0 0.2 1 1725 427 4.64 40.00 42.05 39.00 44.00 20.00 1.30 GHz 0.66 GHz 2.00 GHz
17:16:33 0.6 0.1 2.5 96.7 0.2 1 2385 554 4.67 40.00 42.05 39.00 44.00 20.00 1.51 GHz 0.85 GHz 2.00 GHz
^C-------- ----- ----- ----- ----- ----- ---- ------ ------ ------ ------ ------ ------ ------ ------ ---------
Average 0.7 0.0 1.0 98.2 0.1 1.0 1944.5 480.7 4.54 40.85 42.05 39.08 44.00 20.00 1.47 GHz 0.82 GHz 2.00 GHz
GeoMean 0.7 0.0 0.6 98.2 0.0 1.0 1926.8 477.3 4.53 40.84 42.05 39.08 44.00 20.00 1.46 GHz 0.81 GHz 2.00 GHz
StdDev 0.1 0.1 0.9 1.0 0.1 0.0 272.6 58.6 0.17 0.95 0.00 0.27 0.00 0.00 0.06 GHz 0.08 GHz 0.00 Hz
-------- ----- ----- ----- ----- ----- ---- ------ ------ ------ ------ ------ ------ ------ ------ ---------
Minimum 0.5 0.0 0.1 96.3 0.0 1.0 1725.2 425.8 4.32 40.00 42.05 39.00 44.00 20.00 1.30 GHz 0.66 GHz 2.00 GHz
Maximum 0.9 0.2 2.8 99.2 0.3 1.0 2399.6 591.6 4.86 42.00 42.05 40.00 44.00 20.00 1.54 GHz 0.98 GHz 2.00 GHz
-------- ----- ----- ----- ----- ----- ---- ------ ------ ------ ------ ------ ------ ------ ------ ---------
Summary:
System: 4.54 Watts on average with standard deviation 0.17
C-State Resident Count Latency
C3_ACPI 93.259% 57802 1048
C2_ACPI 3.965% 11732 253
C1_ACPI 0.587% 10731 1
POLL 0.000% 7 0
C0 2.189%
Histogram (of 13 power measurements)
Range (Watts) Count
4.320 - 4.373 3 ########################################
4.374 - 4.428 3 ########################################
4.429 - 4.482 0
4.483 - 4.537 1 #############
4.538 - 4.591 0
4.592 - 4.645 2 ##########################
4.646 - 4.700 2 ##########################
4.701 - 4.754 1 #############
4.755 - 4.809 0
4.810 - 4.863 1 #############
Histogram (of 13 CPU utilization measurements)
Range (%CPU) Count
0.779 - 1.068 4 ########################################
1.069 - 1.357 1 ##########
1.358 - 1.646 3 ##############################
1.647 - 1.936 1 ##########
1.937 - 2.225 0
2.226 - 2.515 1 ##########
2.516 - 2.804 0
2.805 - 3.093 0
3.094 - 3.383 1 ##########
3.384 - 3.672 2 ####################
Histogram (of 13 CPU average frequencies)
Range (GHz) Count
1.301 - 1.324 1 ########
1.325 - 1.349 0
1.350 - 1.373 0
1.374 - 1.398 1 ########
1.399 - 1.422 0
1.423 - 1.446 1 ########
1.447 - 1.471 1 ########
1.472 - 1.495 5 ########################################
1.496 - 1.519 3 ########################
1.520 - 1.544 1 ########
Histogram (of 13 thermal zone x86_pkg_temp readings)
Range (°C) Count
40.000 - 40.199 7 ########################################
40.200 - 40.399 0
40.400 - 40.599 0
40.600 - 40.799 0
40.800 - 40.999 1 #####
41.000 - 41.199 0
41.200 - 41.399 0
41.400 - 41.599 0
41.600 - 41.799 0
41.800 - 41.999 5 ############################
Range is zero, cannot produce histogram of thermal zone SEN1
Histogram (of 13 thermal zone TCPU readings)
Range (°C) Count
39.000 - 39.099 12 ########################################
39.100 - 39.199 0
39.200 - 39.299 0
39.300 - 39.399 0
39.400 - 39.499 0
39.500 - 39.599 0
39.600 - 39.699 0
39.700 - 39.799 0
39.800 - 39.899 0
39.900 - 39.999 1 ###
Range is zero, cannot produce histogram of thermal zone acpitz
Range is zero, cannot produce histogram of thermal zone INT3400 Thermal
Last edited by sga on 2023-06-15 11:48, edited 1 time in total.
-
Aki
- Global Moderator
- Posts: 4149
- Joined: 2014-07-20 18:12
- Location: Europe
- Has thanked: 119 times
- Been thanked: 556 times
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
Hello,
What is output of the cpufreq-info in the two kernels ?
Have you tried to disable temporary the tlp program and let the governor work without possible external interferences ?
There could be other power optimizing software (laptop-mode-tools, for example) concurrently running ?
What is output of the cpufreq-info in the two kernels ?
Have you tried to disable temporary the tlp program and let the governor work without possible external interferences ?
There could be other power optimizing software (laptop-mode-tools, for example) concurrently running ?
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
Old kernel cpufreq-info
New kernel cpufreq-info
I use tlp with many changes, but for cpu, i have primarily only changed the default governor to powersave (i have attached the tlp conf in the og post). On disabling tlp, on newer kernel power draw increased to ~5.2w, and frequency remained near ~2GHz on all cores (the same broken behaviour as with tlp, but increased power draw due to disabling other tlp behaviours), with older kernel, power draw increased to ~4.6w, with interesting thing that now the average frequency of all cores on average was lower (~800Mhz and even lower) than with tlp enabled, which i guess might have to do something with the fact that with tlp, even though average frequency is higher, it does not deviate much and stays within a +-300 MHz range, whereas without tlp, that was about +-500MHz, and i guess changing the frequency continously over range may be more efficient , but this is purely speculative
only other possible things that i have running remotely related to power draw is a upower daemon (which just logs the power usage), and lxqt-powermanagement, and it does not have anything related to cpu scaling, i have only enabled it's idleness checker module, whuch just suspends my laptop after 8 mins of inactivity, for completeness sake, i disabled it, no change is measured. I do not have laptop-mode-tools, power-profile-daemon, auto-cpufreq, powertop daemon, thermald daemon, etc. installed/enabled.
one important thing that i have forgotten to tell is that when suspended, in older kernel, it reaches to a state of 0.25w powerdraw, even with s2idle (my laptop does not support suspend to ram), no such behaviour is observed in newer kernel (power draw remains basically same, due to this, i never suspended my laptop when i used to use arch before)
Code: Select all
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
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: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.01 GHz.
analyzing CPU 1:
driver: intel_pstate
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.06 GHz.
analyzing CPU 2:
driver: intel_pstate
CPUs which run at the same hardware frequency: 2
CPUs which need to have their frequency coordinated by software: 2
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.12 GHz.
analyzing CPU 3:
driver: intel_pstate
CPUs which run at the same hardware frequency: 3
CPUs which need to have their frequency coordinated by software: 3
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 863 MHz.
analyzing CPU 4:
driver: intel_pstate
CPUs which run at the same hardware frequency: 4
CPUs which need to have their frequency coordinated by software: 4
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.00 GHz.
analyzing CPU 5:
driver: intel_pstate
CPUs which run at the same hardware frequency: 5
CPUs which need to have their frequency coordinated by software: 5
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 776 MHz.
analyzing CPU 6:
driver: intel_pstate
CPUs which run at the same hardware frequency: 6
CPUs which need to have their frequency coordinated by software: 6
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.08 GHz.
analyzing CPU 7:
driver: intel_pstate
CPUs which run at the same hardware frequency: 7
CPUs which need to have their frequency coordinated by software: 7
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.02 GHz.
Code: Select all
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
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: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.00 GHz.
analyzing CPU 1:
driver: intel_pstate
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.00 GHz.
analyzing CPU 2:
driver: intel_pstate
CPUs which run at the same hardware frequency: 2
CPUs which need to have their frequency coordinated by software: 2
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.43 GHz.
analyzing CPU 3:
driver: intel_pstate
CPUs which run at the same hardware frequency: 3
CPUs which need to have their frequency coordinated by software: 3
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.00 GHz.
analyzing CPU 4:
driver: intel_pstate
CPUs which run at the same hardware frequency: 4
CPUs which need to have their frequency coordinated by software: 4
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.00 GHz.
analyzing CPU 5:
driver: intel_pstate
CPUs which run at the same hardware frequency: 5
CPUs which need to have their frequency coordinated by software: 5
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.23 GHz.
analyzing CPU 6:
driver: intel_pstate
CPUs which run at the same hardware frequency: 6
CPUs which need to have their frequency coordinated by software: 6
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.00 GHz.
analyzing CPU 7:
driver: intel_pstate
CPUs which run at the same hardware frequency: 7
CPUs which need to have their frequency coordinated by software: 7
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.20 GHz.
only other possible things that i have running remotely related to power draw is a upower daemon (which just logs the power usage), and lxqt-powermanagement, and it does not have anything related to cpu scaling, i have only enabled it's idleness checker module, whuch just suspends my laptop after 8 mins of inactivity, for completeness sake, i disabled it, no change is measured. I do not have laptop-mode-tools, power-profile-daemon, auto-cpufreq, powertop daemon, thermald daemon, etc. installed/enabled.
one important thing that i have forgotten to tell is that when suspended, in older kernel, it reaches to a state of 0.25w powerdraw, even with s2idle (my laptop does not support suspend to ram), no such behaviour is observed in newer kernel (power draw remains basically same, due to this, i never suspended my laptop when i used to use arch before)
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
Same here on old Fujitsu e756 laptop with i3 6th gen. On older kernels 5.10.xx I had lowest frequencies 400 MHz(sometimes 800 jump) most time on idle with powersave governor. After upgrade to Bookworm it stucks mainly on max 2,3 GHz, seldom drops to 400 MHz.
Is it new kernels behaviour, or should I back to Bullseye, maybe report problem? Hmm.
Is it new kernels behaviour, or should I back to Bullseye, maybe report problem? Hmm.
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
Hmm... I didn't measure, but my general impression is that kernel 6.1 (I am talking about the version that comes with Bookworm) does a little bit better in term of battery life. It does worse in terms of memory consumption, but on the other side there are some improvements implemented for btrfs, so let's say that's the price.
What if you force the frequency to the minimum? You can do that with a script or with cpupower-gui.
If you have load (expect this), see which process(es) are using the CPU.
What if you force the frequency to the minimum? You can do that with a script or with cpupower-gui.
If you have load (expect this), see which process(es) are using the CPU.
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
There is no load as when i do most of my power measurement, it is either a cold boot (with or without x), or leave my machine for like 5 mins untouched so that all the things that can be suspended (like browser tabs, text editor, or something else which is not constantly running other than the tool for measurement), so load is not high, using htop to get the cpu % usage, usually in such idle condition is like <0.1%. the power consumption at idle is essentially nothing but a number, (like if i leave everything and turn my screen off, at idle i get the a 0.5-8w stage, which is pretty nice but useless), i can get it to 0 if i dont turn the computer on, the thing that is the issues is that if in a load, if the system can reach a closer to idle state, it consumes less power. In my experience, when i work, i get around 7-8 hours of fair usage (web browsing, music, video playback, and usual work/study stuff, which also includes sporadic but still heavy usage (some heavy programs/or remote operations)) with 5.10, with newer ones i was(never tried full days with the lts 6.1, but power draw is same as others(5.19 which i used quiet a lot)) getting 5 hours of same work, and difference between them is that i can go full day without charging, or charging once(so i also have to carry charger, or atleast not to forget that), and less frequent charging essentialy also means less wear down of battery, if the battery health as reported by upower is to go by, with newer kernels, in 4 months it wore down to 93.4%(it did actually start at about 98.6ish%), and since then using 5.10 for 8 months and it is now 92.5% (these are % empty-full/empty-full-design)
I have learnt that hard settng the frequency to a value is not great, since governors know better, i used to do that and set mine to 400 MHz, and despite being slow, it would not(atleast significantly) improve battery (with newer kernels, at that time i was using arch, power usage would go from ~4.8w to ~4.6w). more than the frequencies, as i get it, the c states are more important, some resource i used when i first got to konw about it (https://metebalci.com/blog/a-minimum-co ... -p-states/)
Battery performance varies very widely with devices and i am glad it got better for you, the title as i wrote is misleeading in the sense that it generalises the problem, and i should fix that, Still thank you all (aki, berad7, undesign) for the advices
On a seperate note, do you have some idea why did memory consumption increase, is the caching a little bit more aggressive, or something?
I have learnt that hard settng the frequency to a value is not great, since governors know better, i used to do that and set mine to 400 MHz, and despite being slow, it would not(atleast significantly) improve battery (with newer kernels, at that time i was using arch, power usage would go from ~4.8w to ~4.6w). more than the frequencies, as i get it, the c states are more important, some resource i used when i first got to konw about it (https://metebalci.com/blog/a-minimum-co ... -p-states/)
Battery performance varies very widely with devices and i am glad it got better for you, the title as i wrote is misleeading in the sense that it generalises the problem, and i should fix that, Still thank you all (aki, berad7, undesign) for the advices
On a seperate note, do you have some idea why did memory consumption increase, is the caching a little bit more aggressive, or something?
Last edited by sga on 2023-06-20 20:36, edited 2 times in total.
-
donald
- Debian Developer, Site Admin
- Posts: 1446
- Joined: 2021-03-30 20:08
- Has thanked: 251 times
- Been thanked: 303 times
Re: Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
@Best_Threads
Typo perfectionish.
"The advice given above is all good, and just because a new message has appeared it does not mean that a problem has arisen, just that a new gremlin hiding in the hardware has been exposed." - FreewheelinFrank
"The advice given above is all good, and just because a new message has appeared it does not mean that a problem has arisen, just that a new gremlin hiding in the hardware has been exposed." - FreewheelinFrank
Re: [Software] Worse Battery life in kernels past v 5.18(may be even earlier)
I do not know what file system are you using, but in my case (btrfs) there are some optimizations / improvements related to that. There are some additional optimizations related to btrfs in kernel 6.3, please read the changelogs.sga wrote: 2023-06-20 20:13 On a seperate note, do you have some idea why did memory consumption increase, is the caching a little bit more aggressive, or something?
As a result:
- file system is faster in some scenarios
- memory consumption increased
Personally I consider this a fair price to pay.
Related to the main topic here: if the battery topic is so important to you (I can understand your point, especially when related to battery wear), there is nothing wrong to stay with Debian 11 (still supported). I can tell you that when I upgraded from kernel 4 to kernel 5, I noticed that the system was a bit slower and the memory consumption increased a bit. But there were other benefits, so I accepted this.
Re: Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
for anyone still looking, this was a problem related to https://lore.kernel.org/all/20230627062 ... intel.com/
and as of today, kernels version 6.4+ are again working as inteded (though htop may still report incorrectly), both cpu scaling and C states are working
Thank You everyone
and as of today, kernels version 6.4+ are again working as inteded (though htop may still report incorrectly), both cpu scaling and C states are working
Thank You everyone
Re: Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
Debian 12 is using kernel 6.1 LTS (not 6.4)
Are you sure your problem is solved with the latest kernel update? If so, that means the respective fix was backported for the entire 6.x kernel.
Are you sure your problem is solved with the latest kernel update? If so, that means the respective fix was backported for the entire 6.x kernel.
Re: Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
No it has been not backported, so unless that is done, 6.1 is no go, problem was due to the fact that, for some devices, if it would reach lower c states, and suspend, it may not wake up, and so they pushed a fix which fixed that by not letting it enter lower c states, but it affected many more devices
The problem was not fixed by updating to latest 6.1, but 6.4.0.1 (in testing) (and for unrelated reasons, i upgraded my whole system to testing)
The problem was not fixed by updating to latest 6.1, but 6.4.0.1 (in testing) (and for unrelated reasons, i upgraded my whole system to testing)
Re: Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
Is there any chance for LTS kernel patch in near future? Any info from developers or something?
I really would like to stay on stable distro.
I really would like to stay on stable distro.
Re: Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
As i understand, this patch is (atleast currently) not in consideration to be backported, though they told battery life being decreased as a serious regression, best thing if you want it to be backported is to probably reply in the linked mail thread
If you are using a device which is effected (to check if at idle your cpus go to lower c states or not via powertop(or powerstat(though i believe with powerstat you would get a little more than idle)), dont check htop, as for these effected devices, htop also can not report correctly), i would recommend (in order of decreasing "official"ness)
1) compile a new kernel (hardest, but could be worthwhile)
2) wait for it to land in backports, as that is the recommended method of getting newer stuff (same difficulty as 3, but it sometimes upgrades other packages, i maybe wrong but i vaguely remember getting newer libreoffice from bullseye backports about an year ago, which may not be ideal, but they are still as stable)
3) you to just add the experimental repo, packages from experimental dont have release candidates, so it will not try to upgrade everything in your system, so you can leave everything in system as it is, and just add new kernel(without meta package)(it should not ask for any newer dependencies(if it does, feel free to reply)), and test if you see improvements (i got even lower power consumption than 5.10 because of other optimisations, especially with bluetooth, where depending upon my headphones, one of them nearly reached wired earphone level power consumption), if not, you can easily remove, though i should warn you, experimental packages are experimental and not meant to be used without any thought. (easiest according to me)(bonus: if you want newer firefox and you use some other packaging format for that, then experimental also have firefox)
4) A kinda better/worse way is via adding testing/unstable repo, then apt pinning all packages in them to lower priorities, and selectively give high priority to the kernel, but this method is comparitively least appreciated for support (insert obligatory frankendebian wiki) (slightly harder than experimental, but pinning is not recommended)
(If you must, you may also try some other kernel sources like liquorious/xanmonad kernel/ etc, then possibly the support by debian would be least, but they support and provide repos for debian)
If you are using a device which is effected (to check if at idle your cpus go to lower c states or not via powertop(or powerstat(though i believe with powerstat you would get a little more than idle)), dont check htop, as for these effected devices, htop also can not report correctly), i would recommend (in order of decreasing "official"ness)
1) compile a new kernel (hardest, but could be worthwhile)
2) wait for it to land in backports, as that is the recommended method of getting newer stuff (same difficulty as 3, but it sometimes upgrades other packages, i maybe wrong but i vaguely remember getting newer libreoffice from bullseye backports about an year ago, which may not be ideal, but they are still as stable)
3) you to just add the experimental repo, packages from experimental dont have release candidates, so it will not try to upgrade everything in your system, so you can leave everything in system as it is, and just add new kernel(without meta package)(it should not ask for any newer dependencies(if it does, feel free to reply)), and test if you see improvements (i got even lower power consumption than 5.10 because of other optimisations, especially with bluetooth, where depending upon my headphones, one of them nearly reached wired earphone level power consumption), if not, you can easily remove, though i should warn you, experimental packages are experimental and not meant to be used without any thought. (easiest according to me)(bonus: if you want newer firefox and you use some other packaging format for that, then experimental also have firefox)
4) A kinda better/worse way is via adding testing/unstable repo, then apt pinning all packages in them to lower priorities, and selectively give high priority to the kernel, but this method is comparitively least appreciated for support (insert obligatory frankendebian wiki) (slightly harder than experimental, but pinning is not recommended)
(If you must, you may also try some other kernel sources like liquorious/xanmonad kernel/ etc, then possibly the support by debian would be least, but they support and provide repos for debian)
Re: Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
Thanks for reply.
All I need is just fixed kernel and no-rolling release without frequent system updates. I don't care newest packages, so I could also consider backing to Debian 11.
All I need is just fixed kernel and no-rolling release without frequent system updates. I don't care newest packages, so I could also consider backing to Debian 11.
Re: Worse Battery life, with 11th gen i3 in kernels past v 5.18(may be even earlier)
If you compile or use experimental(or use other kernel sources without installing their meta package), they basically stay fixed, nothing else gets upgraded, and you would only get updates to that kernel, but you may as well use debian 11, it is still supported fairly well