The MicroSD card for whatever reason draws a lot of power. You might try your test again with it removed. The USB-A is lower, but still a small draw.
Regarding suspend-then-hibernate, I will have to revisit the steps that I took. My recollection is that it involves first setting the system up so that hibernate is an option. Once that has been done, then one needs to enable the setting in a config file and set the time before hibernate in another. I am on Manjaro now, so the config files may be slightly different than Debian.
This thread has very complete measurements on power use during “normal power on”, s2idle, and deep:
The expansion cards have a non-negligible power use during s2idle/deep.
For your measuring accuracy: I wouldn’t go with “estimated time till drained”, since that involves a highly variable estimate of power use-while-on. I think you’ll get more reliable results by querying the estimated charge of the battery (in mAh or in W). It’s not perfect either, but the runtime estimate is based on it, so you’'ll get more stable results.
May be I’m quite naive but if I would design a suspend mode I would switch of all extensions if nothing is plugged in. I admit I need the MicroSD card extremely rarely (would love to have a normal SD card extension) but simply leaving the slot empty to save battery seems to be quite strange.
Hello @Andreas_Tille best tip I have for you is to make this file etc/udev/rules.d/10-runtime-pm.rules as mentioned in a solution to this question over at serverfault
This one solution basically corrects mostly all the “bad” errors powertop will show.
Additionally, I have configured power profile daemon to stay on power save while on battery, it gives me an hour or so of extra battery time.
For a more “do it for me” approach, install TLP with its defaults is “pretty good.”
My rationale for recommending TLP first is that it doesn’t really do anything drastic that might create unintended behavior.
Short version: If your focus is taking care of those tunables, Cipher’s recommendation is absolutely the way to go. If you are “okay” with one or two of them being bad, default TLP is also fine.
Anything pulling power is going to be a consideration. Modules connected for DisplayPort, HDMI, etc. PowerTOP can give you it’s best guess estimates for sure. But even after running calibration, PowerTOP isn’t going to be exact. It will fluctuate.
@Lamy It’s tough. I’m brand new, so I have not had time to do any proper benchmarking…yet.
The best thing to do until I have time to really dial this:
Make sure you’re using the latest available firmware.
Some expansion modules will use more power than others.
Early testing has me on Fedora 37, latest kernel 22.214.171.1240, YT video on a loop. No touchpad interaction with PowerTOP open is looking to be 3-5 hours, likely will hit 4 hours with YT playing the entire time.
My daily use sees about 4-6 hours depending how much I use.
To get really dialed in information on discharge rates, please use this command in the terminal for discharge rates:
Yesterday night I had put my Ubuntu 22.04 in sleep and went to bed. Today morning, I could boot only after charging the battery for at least a minute and saw that the battery was at 2%. Clearly the battery has completely discharged overnight in a span of about 8 hours.
We have 2 LEDs on our laptop. One is used while the laptop is charging from its 2 USB C ports. May be one could have a setting in the bios, that when enabled can use another LED to glow continuously if the rate of discharge of battery is beyond certain percentage say 5%. And may be both LEDs can glow when the laptop is not being charged at all!
So, if I suspend my laptop and see that the LED is glowing I would know that something is wrong and I would do the shutdown.
@lbkNhubert Thanks to the hints in this thread my laptop does now way better. Thanks a lot to all who provided helpful suggestions. The only thing I did not got working is the suspend-then-hibernate method. I did as suggested
In /etc/systemd/logind.conf I have the following relevant lines:
Thanks for the update. Early testing thus far on my end:
Note, because attaching anything is naturally a potential power draw if it fails to suspend with the laptop, this was done as a suspended laptop Framework laptop only. No applications loaded, next round will be with Chrome open and then suspended.
Ubuntu 22.10 on 12th gen, overnight lid close suspend with a 90% charge, late afternoon following day, 80% - this isn’t bad. 126.96.36.199 kernel, s2idle is deep. Wi-Fi had question mark reconnect, shows question mark, but INTERNET IS WORKING.
Ubuntu 22.04 on 12th gen, overnight lid close suspend with a 90% charge, late afternoon following day, 80% - this isn’t bad. 188.8.131.52 kernel, s2idle is deep. Wi-Fi displays normal and also connects fine.
Next will be Fedora 37 testing.
In the meantime, please feel free to open a ticket and they’ll ask you to follow a specific set of guidelines to gather specific logs. This will allow me to better see what is happening at tier 3 support.
@lbkNhubert I wasn’t not happy with the early tests, going to re-do them with matching cards as much as I have available (multiple laptops). Saw something with Fedora 37 that had me go “hmmm”, so I want to re-run this in a more consistent way.
Going to update this tomorrow after re-testing accordingly:
Pop OS 22.04, Ubuntu 22.04 and Fedora 37.
TLP on Ubuntu and Fedora, system76-power on Pop OS.