Counter intuitive maybe, but does the 13gen CPU “support” this? What happens with s2idle instead?
That’s crazy high, what does powertop blame?
Seeing the following in powertop
Summary: 733.1 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 22.1% C
Usage Events/s Category Description
3.3 ms/s 199.2 Timer tick_sched_timer
3.7 ms/s 195.2 Interrupt [43] idma64.2
73.9 ms/s 91.7 Interrupt [14] INTC1055:00
8.4 ms/s 55.0 Process [PID 24741] /opt/google/c
545.2 µs/s 24.0 Process [PID 15] [rcu_preempt]
1.9 ms/s 22.6 Timer hrtimer_wakeup
31.8 ms/s 9.3 Process [PID 2823] /usr/bin/gnome
30.9 ms/s 9.4 kWork intel_atomic_commit_work
1.8 ms/s 18.1 Interrupt [181] i915
121.9 µs/s 9.7 kWork psi_avgs_work
23.1 ms/s 0.4 Process [PID 277] [irq/164-PIXA38
215.2 µs/s 9.2 kWork intel_atomic_cleanup_work
17.2 µs/s 6.3 kWork intel_atomic_helper_free_
For comparison here’s my 11th gen. I don’t even run TLP on this machine. I’m not sure what to suggest, things I’d look into on your machine is what is related to idma64.2 and especially INTC1055:00.
The battery reports a discharge rate of 6.26 W
The energy consumed was 126 J
The estimated remaining time is 7 hours, 21 minutes
Summary: 411.9 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 10.6% CPU use
Usage Events/s Category Description
3.2 ms/s 229.7 Timer tick_sched_timer
39.4 ms/s 9.4 Process [PID 2731] /usr/bin/gnome-shell
484.6 µs/s 24.4 Process [PID 16] [rcu_preempt]
130.6 µs/s 17.0 kWork psi_avgs_work
670.2 µs/s 11.2 Timer hrtimer_wakeup
86.9 µs/s 10.6 kWork engine_retire
13.0 ms/s 4.4 Process [PID 3851] /usr/bin/tilix --gapplication-service
30.4 µs/s 9.4 kWork toggle_allocation_gate
14.6 ms/s 3.6 Process [PID 11526] /usr/lib64/firefox/firefox
23.6 µs/s 8.8 kWork rps_work
547.0 µs/s 8.4 Interrupt [145] i915
315.5 µs/s 6.1 Interrupt [0] HI_SOFTIRQ
12.1 ms/s 0.15 Process [PID 15046] /usr/lib64/firefox/firefox -contentproc -childID 15 -isForBrowser -prefsLen 32569 -prefMapSize 247730 -jsInitLen 23
2.0 ms/s 3.9 Process [PID 1396] /usr/lib/systemd/systemd-oomd
86.3 µs/s 4.4 kWork __intel_wakeref_put_work
80.3 µs/s 4.4 kWork intel_atomic_cleanup_work
0.0 µs/s 4.3 kWork intel_atomic_commit_work
327.8 µs/s 2.9 Process [PID 15055] /usr/lib64/firefox/firefox -contentproc -childID 15 -isForBrowser -prefsLen 32569 -prefMapSize 247730 -jsInitLen 23
293.2 µs/s 2.8 kWork kcryptd_crypt
189.6 µs/s 2.5 kWork __i915_gem_free_work
11.8 µs/s 2.5 Interrupt [6] tasklet(softirq)
61.3 µs/s 2.1 Interrupt [142] nvme0q5
15.6 µs/s 2.0 kWork intel_display_power_put_async_w
23.2 µs/s 1.9 Process [PID 69] [kcompactd0]
0.8 ms/s 1.5 Process [PID 1430] /usr/libexec/iio-sensor-proxy
16.4 µs/s 1.8 Timer watchdog_timer_fn
You might be on to something there - thanks.
Both of those are touchpad interrupts - discussed over here.
It sounds like this may be the source of the issue while awake, which is great as presumably its fixable (although that thread hasn’t been touched bar me in 2 months), which will help at least with the wake power consumption.
Having not really done anything with the device other than write these couple of posts, I’m now down at 16% having slept overnight, which seems pretty unusable.
1 Like
Looks like 23.04 is not officially supported. Have you tried 22.04?
Hi @Bdav,
Do try s2idle for suspend, reboot.
What expansion modules do you have installed? Are they older gen modules or new/firmware upgraded?
- HDMI generations.
- DP generations
- Connected to anything else at all, displays, other peripherals?
Many thanks for the response - have udpated to s2idle in grub config, updated, rebooted and it appears as the default in mem_sleep now so will see what happens overnight.
Nothing much to speak of on the expansions - 3x USB-C and 1x USB-A, not connected to anything else.
2 Likes
Hi there I have the 12th gen Ubuntu 22.04 and the idle works like a charm from day one. I never power off the computer, and when its unplugged I get it in the morning maybe with 5 or 10% less, unsure exactely but its very acceptable.
Today I have been using it uplugged at a meeting, working for maybe one hour on the go…and back at hotel It says 4 hours left.
Its pretty consistent I get 5 hours ish battery.
Now running kernel 6.1 OEM thingy
6.1.0-1013-oem
Ha yes, western digital seams a prety bad option with bugs , don t understand why they are using it. Got a samsung and no problems there
Made the changes as suggested by @Matt_Hartley , as well as removing the USB-A - We’re looking a lot lot better now:
~ python3 /opt/batterylog/batterylog.py ✔
Slept for 10.03 hours
Used 3.44 Wh, an average rate of 0.34 W
At 0.34/Wh drain you battery would be empty in 144.60 hours
For your 60.25 Wh battery this is 0.57%/hr or 13.65%/day
I will try again with the USB-A in and see if I get similar!
Many thanks for the pointers.
8 Likes
Similar time, with USB-A also in. Negligible difference (i.e. still acceptable drain) - many thanks!
I suspect deep sleep isn’t (well) supported on the 13th gen.
~ python3 /opt/batterylog/batterylog.py ✔
Slept for 10.58 hours
Used 3.61 Wh, an average rate of 0.34 W
At 0.34/Wh drain you battery would be empty in 145.13 hours
For your 60.25 Wh battery this is 0.57%/hr or 13.58%/day
~
4 Likes
As a point of comparison:
$ cat /sys/power/mem_sleep
[s2idle] deep
$ /opt/batterylog/batterylog.py
Slept for 13.05 hours
Used 8.62 Wh, an average rate of 0.66 W
At 0.66/Wh drain you battery would be empty in 67.65 hours
For your 53.47 Wh battery this is 1.24%/hr or 29.67%/day
System summary:
CPU: 12-core (4-mt/8-st) 12th Gen Intel Core i7-1260P (-MST AMCP-)
speed/min/max: 2209/400/4700:3400 MHz Kernel: 6.1.0-1014-oem x86_64
Up: 1d 51m Mem: 3791.9/31801.0 MiB (11.9%) Storage: 1.83 TiB (18.1% used)
Procs: 432 Shell: Sudo inxi: 3.3.13
Expansion modules: 1 x USB-A, 1 x USB-C, 1 x microSDXC and 1 x 1 TB.
Dino
This would be an interesting comparable for sure.
Think this can be marked as resolved. Unless we’re still really disappointed.
For battery drain numbers, maybe head over here:
1 Like
As a comparison for you @Bdav
My framework is 13th Gen 1340p, 32GB RAM. 3 x USB C and 1 x USB A. I’m on Fedora 38.
/opt/batterylog/batterylog.py
Slept for 12.96 hours
Used 5.00 Wh, an average rate of 0.39 W
At 0.39/Wh drain you battery would be empty in 49.16 hours
For your 54.84 Wh battery this is 0.70%/hr or 16.90%/ day
1 Like
Alright, consensus is to mark this solved?
3 Likes
Yesterday presented the first opportunity I’ve had to remove all cards and close the lid for a meaningful amount of time.
$ inxi
CPU: 12-core (4-mt/8-st) 12th Gen Intel Core i7-1260P (-MST AMCP-)
speed/min/max: 2183/400/4700:3400 MHz Kernel: 6.1.0-1014-oem x86_64
Up: 2d 18h 53m Mem: 2828.2/31801.0 MiB (8.9%)
Storage: 465.76 GiB (39.7% used) Procs: 447 Shell: Bash inxi: 3.3.13
$ cat /sys/power/mem_sleep
s2idle [deep]
$ /opt/batterylog/batterylog.py
Slept for 15.92 hours
Used 2.82 Wh, an average rate of 0.18 W
At 0.18/Wh drain you battery would be empty in 286.73 hours
For your 53.62 Wh battery this is 0.33%/hr or 7.92%/day
That’s almost 12 days of idle time. Even though I’ve read most of the “battery life” threads on the forum, I was surprised by how much energy the cards consume while doing nothing.
Dino
1 Like
While pondering the difference in the battery discharge rate captured in my two contributions to this thread I had a wtf moment. I seldom, if ever, examine /sys/power/mem_sleep. When I pasted its content into my original post I didn’t notice that it was [s2idle]. I explicitly set it to [deep] on the command line:
$ cat / proc / cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-1014-oem root=/dev/mapper/sysvg-root ro quiet splash mem_sleep_default=deep
I’ve no idea what caused it to change. Nevertheless, the mem_sleep during my original batterylog capture was s2idle; the most-recent one was deep.
Dino
edit: a bug in the forum posting tool is preventing me from pasting or typing ‘proc’ and ‘cmdline’ separated by forward slashes. Attempting to save a post with that character sequence pops up a message box that says: “403 forbidden”…
Thanks @truffaldino - thats really interesting. Would be interesting to see the original in [deep] - I think you’ve confirmed though that the standby draw on the cards is a big issue - as noted by the post linked further up.
@Matt_Hartley - Many thanks, yes in terms of the core laptop itself this all looks great now, thanks for looking it over. I’d suggest theres still work (presumably in Firmware) to do around the stby current draw on the non-USB-C cards.
$ cat /sys/power/mem_sleep
s2idle [deep]
$ /opt/batterylog/batterylog.py
Slept for 11.68 hours
Used 7.92 Wh, an average rate of 0.68 W
At 0.68/Wh drain you battery would be empty in 63.85 hours
For your 51.04 Wh battery this is 1.33%/hr or 31.87%/day
Expansion card composition and system configuration is as in the original post (no. 12 in this thread).
Dino