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.
I looked at the page you reference (https://ark.intel.com/content/www/us/en/ark/products/208658/intel-core-i51135g7-processor-8m-cache-up-to-4-20-ghz.html), and I couldn’t find the string “ACPI” in it. Could you quote the section that talks about the sleep states?
You go to Technical Documentation, then Datasheets and Specifications, and I found it on 1 of 2, on page 61.
I think mine’s going into suspend then hibernating, as it takes longer to wake up when it’s been asleep awhile. Is there an easy way to verify?
Found the following in my latest boot journal:
kernel: PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
Does this means it hibernated or merely configured to hibernate?
It takes roughly a minute to fully wake from hibernate, which I can live with. As-is, I’d call it a successful experiment.
A full minute? Damn. I was considering setting up hibernation but I think I might just have the system shut itself off after being asleep for a while. Boot only takes 15 seconds or so.
1 Like
I get something like this with suspend-then-hibernate on Fedora:
in journal logs
Nov 09 04:05:54 framedora systemd-logind[834]: Suspending, then hibernating...
Nov 09 06:06:00 framedora systemd-sleep[68762]: Entering sleep state 'hibernate'...
Nov 09 06:06:00 framedora kernel: PM: hibernation: hibernation entry
Nov 09 17:40:57 framedora kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
Nov 09 17:40:57 framedora kernel: PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff]
Nov 09 17:40:57 framedora kernel: PM: hibernation: Marking nosave pages: [mem 0x39f99000-0x3a898fff]
Nov 09 17:40:57 framedora kernel: PM: hibernation: Marking nosave pages: [mem 0x3f80e000-0x3f85cfff]
Nov 09 17:40:57 framedora kernel: PM: hibernation: Marking nosave pages: [mem 0x3f85e000-0x3f85efff]
Nov 09 17:40:57 framedora kernel: PM: hibernation: Marking nosave pages: [mem 0x3f8ca000-0x3f8cafff]
Nov 09 17:40:57 framedora kernel: PM: hibernation: Marking nosave pages: [mem 0x434af000-0x45bfefff]
Nov 09 17:40:57 framedora kernel: PM: hibernation: Marking nosave pages: [mem 0x45c00000-0xffffffff]
Nov 09 17:40:57 framedora kernel: PM: hibernation: Basic memory bitmaps created
Nov 09 17:40:57 framedora kernel: PM: hibernation: Preallocating image memory
Nov 09 17:40:57 framedora kernel: PM: hibernation: Allocated 4781969 pages for snapshot
Nov 09 17:40:57 framedora kernel: PM: hibernation: Allocated 19127876 kbytes in 2.49 seconds (7681.87 MB/s)
Nov 09 17:40:57 framedora kernel: PM: hibernation: Creating image:
Nov 09 17:40:57 framedora kernel: PM: hibernation: Need to copy 4750531 pages
Nov 09 17:40:57 framedora kernel: PM: hibernation: Normal pages needed: 4750531 + 1024, available pages: 11970033
Nov 09 17:40:57 framedora kernel: PM: hibernation: Basic memory bitmaps freed
Nov 09 17:40:57 framedora kernel: PM: hibernation: hibernation exit
Which clearly shows it entering suspend-then-hibernate, then hibernating with no errors, and finally exiting hibernation when I turn the computer back on. If entering hibernation fails, there should be error(s) in the log describing suspend-then-hibernate failing to enter hibernate (and perhaps falling back to suspend).
Also, resuming from hibernation should be similar to a cold boot. In my experience, this means the grub menu shows and then the Framework splash screen.
As another data point, on Fedora 35 with 25% of 64gb of ram used:
Takes about 60 seconds to enter hibernation, and a little under 45 seconds to resume.
RAM size (and how much needs to be written to disk) + SSD speed probably affects how long it takes to hibernate/resume. I myself am not on the fastest ssd (an old liteon). I don’t mind the time it takes to enter hibernation since I can just close the lid. As for resume time, it’s probably faster with less ram + faster SSD.
I’m also disabling zram before hibernation and writing to a swapfile, FWIW.
Being able to have the system completely off for extended periods where I don’t want battery drain and then resuming into whatever I was doing before is worth the relatively long resume for me. s2idle’s instant wakeup + hibernation is working pretty well for me, but I wish s2idle would drain way less battery.
For what it’s worth, I’m on Fedora F35 (5.14.17-301.fc35.x86_64) and I’ve done some experimentation, with s2idle and deep sleep. I’m seeing ~4% drain per hour on s2idle and 2% drain per hour on deep sleep. I’ve done some short experiments with turning off WiFi / Bluetooth, and unplugging USB peripherals, but don’t it doesn’t seem to make much difference in the rate of discharge. Overall, I think deep sleep is at an acceptable level, however I do find it annoying that it takes so long to wake from deep sleep (usually it’s a good 15 - 20 seconds). I may eventually come up with a script that starts sleep in s2, and goes to deep after 1 hour or so, such that if I close the lid for a short period of time (let’s say walking around the house) I can resume quickly, but overnight or in transit, I can benefit from good power savings. If anyone has done this already, please post.
FYI my specs are:
i7-1165G7
32 GB RAM - single slot
AX210 (with vPro) - IDK why I got vPro, since my CPU doesn’t support vPro, and apparently vPro Wifi can contribute to power drain…
SN850 1TB SSD
HDMI, Display Port, USB-A, USB-C ports
1 Like
Why not just do suspend-then-hibernate? Hell, hibernate has way better powersavings than even deep sleep.
2 Likes
Hibernate is not available, I believe due to secure boot being enabled upon installing Fedora. From what I understand, I’d have to re-install with secure boot turned off to enable hibernate.
1 Like
No, you can just toggle secure boot in the UEFI settings. You’d have to reinstall if you wanted to switch from BIOS to UEFI or vice versa (source: I did the same thing where I installed Debian with secure boot enabled but later disabled it so that I could hibernate).
2 Likes
That worked, thanks.
1 Like
Has anyone tried getting Intel Rapid Start to work (or maybe just knows more about it than I do and can say if that’s even feasible)? Power management/Suspend and hibernate - ArchWiki
It seems like it’s an Intel-specific, faster better version of hibernation, but other than that little section in the Arch Wiki, I really can’t find much info on it. Apparently it requires a special partition, and:
there’s no obvious indication to the OS that the feature is supported unless the appropriate partition already exists
Which seems like the perfect formula for spending a whole afternoon messing with partitioning and whatnot without any indication of whether or not what you’re doing will result in anything useful. But, if it’s actually supported it seems very worthwhile.
In my opinion, s2idle with suspend-then-hibernate is the answer to this conundrum. It provides quick, trouble free suspend/resume and low battery degradation over the long term. Suspending to deep kills the battery if you leave the laptop for longer periods between uses as it constantly drains the battery.
suspend-then-hibernate is problematic for a number of reasons, and s2idle drain really needs to improve for this to be a complete product:
- It doesn’t work with secureboot (it might in the future, details here: mjg59 | Making hibernation work under Linux Lockdown)
- It doesn’t work with Zram, which is default on Fedora (and maybe other distros)
- Swap space has to be large, and cannot be encrypted (yet?)
- Combining this with a BIOS password (which is best practice for workstations) and LUKS encryption means having to type credentials in many times during wake
- 20 second (plus multiple password typing) boot times is unreasonable for many people
I see in some other threads that Windows users got s0ix drain down to ~150-500mW. That’s a much better level than the current 2.2W (calculated from 4% drained per hour on the 55Wh battery)
I know that Framework is a small company with a small dev team, and doesn’t have many resources to allocate to fix these problems.
If this doesn’t get fixed soon I’m either going to request a refund (still within my 30 day return window) or donate it to a Linux dev who can make power management work with all the hardware in the device.
2 Likes