@Carlos_Fernandez_San "uname -a output"
Linux my-fedora 5.14.12-300.fc35.x86_64 #1 SMP Wed Oct 13 14:16:09 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
No luck for with 5.14.12 from Ubuntu. I checked the changelog from fedora and there’s a lot of changes there so probably one of them is what I need, but who knows 
I’ll stick to 5.12 for now.
PSA, just because I spent way too much time finding these, the datasheet is listed here: Intel Core i51135G7 Processor 8M Cache up to 4.20 GHz Product Specifications
It supports S3, S4, and S5. S3=deep. S0=s2idle.
Linux states and files explained: System Sleep States — The Linux Kernel documentation
Both documents do a good job explaining things. In the datasheet search for “ACPI”.
FWIW I’d like to get hibernation working, but this looks like more time than I have right now.
2 Likes
More good stuff, I found this:
And using the instructions, the low_power_idle_system_residency_us counter is indeed increasing, and resuming from standby is dramatically better than deep. I will try this overnight and post my results.
31% loss in 4 hours. I am most disappointed. edit: this is fedora 35 beta, I will reply if it gets any better over time but I’m not feeling hopeful.
That’s odd. As I posted at the link below, I’m also on Fedora 35 beta but I’m seeing the same amount of battery loss in 11 hrs of suspend as you are in 4 hrs. What “Power Saver” profile are you using?
Looking forward to hearing your results. Because 2% in 2 hours is excellent.
Oof, looks like I’ll need to do some tweaking because the numbers are a lot worse than I’d like for battery life under suspend… These numbers are still from s2idle – I haven’t touched any suspend related configs.
My setup:
- DIY edition
- i7 65G version
- 32GB DDR4 memory
- 1TB PCIe gen3 nvme
- 2 USB-C + 1 USB-A + 1 MicroSD cards
- Arch (stock kernel 5.14.14)
I was at 80.2% last night.
I dropped to 48.6% from 11hrs + 17min suspend time.
That’s about 2.8% lost per hour.
Just another data point: 19% over 12 hours with deep sleep enabled
- DIY Edition
- i5-1135G7
- 16GB DDR4 (single SODIMM)
- 512GB gen3 NVME
- 2 USB-C + 2 USB-A
- Fedora 34 (kernel: 5.13.19-200)
That is really great. I think the amount of RAM factors in here rather significantly. I have 64GB on mine, and I’m guessing I’ll see something closer to hspak.
I suspended at 67% just now.
Is there a decent solution to battery-drain post-install on Fedora 35 yet? Deep sleep didn’t bother me initially, but the amount of time it’s been taking to resume from sleep has been unacceptable for me. I’m open to figuring out hibernation, but it doesn’t seem like it’ll solve much in terms of wake time.
How much wake time delay are we talking about here? If you’re going to save more battery during sleep, sounds like a pretty good tradeoff to me.
At least 10-20 seconds between input and the display lighting up, as someone who works in bursts, it absolutely is not worth the trade off. I’ve switched back to s2 sleep and downloaded TLP since several community members have reported forcing deep sleep doesn’t have significant impact on battery life while crippling time to wake.
3 Likes
Over 5 hours, the drain rate with deep sleep was 7.4% (with 64GB RAM).
The next thing I’m going to look into his suspend + hibernate.
Same amount of RAM that I have. You are seeing ~1.4% an hour which is not bad considering all the RAM that needs to be kept alive.
Fingers crossed that tonight’s soak is informative. I have suspend-then-hibernate enabled, so it should enter deep sleep for an hour, and then switch to hibernate.
Hi everyone. If you want a bit better way to measure power usage than “X% over 10-12 hours”, try this script. It times it to the second and reads the battery charge reported to Linux via ACPI to get a resolution of about 0.03%.
#!/bin/bash
# Script to suspend and measure how it did.
if ! [[ "$1" =~ ^[0-9][0-9]*$ ]]; then
echo "USAGE: $0 <seconds>" >&2
exit 1
fi
# Record current s0ix state counters before suspending.
declare -A RES0
while read -r K V; do
RES0[$K]=$V
done < /sys/kernel/debug/pmc_core/substate_residencies
# Record current battery charge and timestamp before suspending.
C0=$(</sys/class/power_supply/BAT1/charge_now)
T0=$(date +%s.%N)
# Suspend! Also collect some stats.
turbostat --quiet --show SYS%LPI,PkgWatt,CorWatt,GFXWatt,RAMWatt rtcwake -m mem -s "$1"
# Record timestamp and battery charge after resuming.
T1=$(date +%s.%N)
C1=$(</sys/class/power_supply/BAT1/charge_now)
# Read s0ix state counters after resume, and calculate time spent in each.
while read -r K V; do
if [[ "$V" != "Residency" ]]; then
T=$(( V - RES0[$K] ))
printf "%s: %d.%06d\n" $K $((T/1000000)) $((T%1000000))
fi
done < /sys/kernel/debug/pmc_core/substate_residencies
# Calculate power usage. The conversion from amps to watts is a guess that seems reasonable, the battery reports a design charge of 3.572 Ah and is supposedly 55 Wh.
perl -lwe '
($c0, $c1, $t0, $t1)=@ARGV;
$c = ($c0 - $c1) / 1e6;
$t = $t1 - $t0;
printf "Used %g Ah in %gs => %g A\n", $c, $t, $c/($t/3600);
$w=$c * 15.4;
printf "Used %g Wh in %gs => %g W\n", $w, $t, $w/($t/3600);
$p=$w / .55;
printf "Used %g%% in %gs => %g%%/h\n", $p, $t, $p/($t/3600);
' $C0 $C1 $T0 $T1
The output looks something like this:
rtcwake: wakeup from "mem" using /dev/rtc0 at Wed Oct 27 03:38:34 2021
28049.122198 sec
SYS%LPI PkgWatt CorWatt GFXWatt RAMWatt
99.71 0.15 0.00 0.00 0.00
99.71 0.15 0.00 0.00 0.00
S0i2.0: 0.000000
S0i3.0: 27965.196423
Used 1.092 Ah in 28049.1s => 0.140154 A
Used 16.8168 Wh in 28049.1s => 2.15837 W
Used 30.576% in 28049.1s => 3.92431%/h
Those are fairly typical results for me using s2idle. Debian unstable, kernel 5.14.12, DIY i7-1165G7, 2×16GB RAM, WD SN850 500GB, 2×USB-C 2×USB-A, AX210 non-vPro.
If you’re doing an overnight test, easiest is to tell it to sleep for longer than you expect (e.g. 86400 seconds) then close the lid. Opening the lid again in the morning should wake it early.
The thing that seems to make the biggest difference for me is whether I have the USB-A cards plugged in. If I take both of them out, it drops by about 1/3. Slot doesn’t matter, but putting both on the same side seems to take slightly less power. The USB-C cards don’t have such an impact. I haven’t tested others.
Power usage in “deep” seems a little more complex. If I do a 5-minute sleep the power usage is the same as with s2idle. But after that it drops, so I suspect the bios may do some additional powering down at that point. Personally I hate the 12-second delay in waking so I’m trying to get s2idle working as well as I can.
7 Likes
According to another thread, USB C cards are simple passthrough and they do not pull any additional current. Everything else does. This is one of the things the team at Framework is looking to improve.
I had my Framework enter deep sleep yesterday at 5:30PM, hibernating an hour later. I woke it at 9AM, with 97% battery available.
It takes roughly a minute to fully wake from hibernate, which I can live with. As-is, I’d call it a successful experiment.
2 Likes
For some reason, when I try to wake from deep sleep, my entire filesystem gets unmounted. Not sure if its because I have the same Sabrent Rocket 4.0 that someone else had problems with, or something with my kernel.
Luckily, however, suspend then hibernate works like a dream, even with s2idle enabled.