High Battery Drain During Suspend

Also make sure any USB devices are unplugged. I noticed that the lap desk continued to be powered even after full power shutdown.

Hi!
I’m using Arch on kernel 5.15, with deep sleep mode turned on:

cat /sys/power/mem_sleep
s2idle [deep]

I read the links posted, and seems I have everything as expected in terms of configuration.

Battery is almost completely drained over the night when suspending the machine.

Don’t know what else to do, but looks like this is a laptop issue, and I would like the company to help us solve this issue, as it’s very annoying!

Thank you very much, any further advice/help is appreciated.

1 Like

I’m having the same level of drain at this point. Did you ever find a solution?

I’ve only got USB-C and USB-A cards installed.

I have usb c x 2, usb A and hdmi cards.

Didn’t find a solution (and tried everything posted here).
I’m very annoyed.
Now I have a laptop that I have to constantly plug, because half of the times when I open the lid to get back to work, battery is already drained.
This is not only annoying, is also not good for the battery.

The lack of response from the company is also quite disappointing… I bought this laptop specifically for Linux, and turns out is not working properly on it. :frowning:

1 Like

The drain is categorized in some cases.

Drain in suspend, sleep state: I see you are trying to deep sleep as a sleep state. If you use hibernation as a suspend state, you can expect a better battery life. I haven’t tried the hibernation by myself as I have a concern about it, Fedora Linux 35 (Fedora 35) on the Framework Laptop - #75 by junaruga . But some people tried and, and reported a better battery in sleep state.

Drain in the normal state: What is your BIOS version? (sudo dmidecode -s bios-version). I remember one person reported that they saw dramatically the battery life improvement by upgrading to the latest BIOS version 3.07.

Did you check the following threads about the buttery life tuning? That is to set up powertop, tlp with a proper setting, and etc.

Drain in completely shutdown (switched off) state: Battery slowly drains when completely shut down

I tried to gather some quantitative measurements on power-use. This is with

  • Fedora Core 35 with TLP installed, running default Gnome/Wayland as desktop
  • 11th Gen Intel(R) Core™ i7-1165G7 @ 2.80GHz
  • 16 GB of main memory installed
  • Bluetooth and WiFi on (Wifi connected; Bluetooth not actually being used)
  • kernel 5.15.18-200.fc35.x86_64 (awaiting clean-up of the 5.16 regressions)

I’ve measured charge drain by looking at /sys/class/power_supply/BAT1/charge_now. As far as I can tell, this reports in µAh, and it looks like the system normally converts this to Wh by multiplying with the value in /sys/class/power_supply/BAT1/voltage_min_design which seems to report 15.4V (in µV). So as far as I can tell the charge in µAh can be converted to Wh by multiplying by 1.54e-5

I’ve sampled the charge in 1 minute intervals, storing a time stamp with it, and then computed the average power drain over relevant periods by dividing by the time elapsed (when the system is suspended, obviously no measurements are recorded, but the time stamps tell you when the measurements were taken)

Measurements were mainly made when the battery was in the 40%-80% charge range.

I was mainly interested in determining the idle power drain, so I’ve mainly used measurements over periods where I was not using the computer.

System on, locked and screen off, with HDMI & USB expansion cards: around 3W

s2idle sleep with USB-A and HDMI expansion cards: around 1.9 W

s2idle sleep with only USB-C expansion cards: around 0.8 W

deep sleep with USB-A and HDMI expansion cards: around 0.9 W

deep sleep with only USB-C expansion cards: around 0.4 W

Conclusions:

  • The normal idle power drain on the system is pretty good! Even with the screen on and no/very little work happening (reading a PDF document?) I’ve seen power drains around the 4W range (with low screen brightness). It doesn’t seem to matter very much if the HDMI and USB-A cards are inserted.

  • s2idle is really quite disappointing: it doesn’t even double the time the battery will last compared to just leaving the machine on! Removing the USB-A and HDMI cards improves the situation a little bit.

  • deep sleep is very badly impacted by USB-A and HDMI cards. I don’t know if the base line 0.4W is as expected to keep 16Gb of memory functioning. With a 55W battery, it certainly does give a respectable suspend time.

It may well be that my methodology can be improved, but it feels to me these are figures that reflect how I’d consider “not using” the machine (for use, obviously I’d expect more power use, but then I’m getting something for it).

I really hope something can be done (in linux? in the BIOS?) to reduce the penalty of having a USB-A and HDMI card present. Presently, the locking system on the cards is so tight that unplugging them is really quite uncomfortable. I did install one on each side, because I want to have a USB-C on either side, for choosing charging position.

I bought the USB-A and HDMI mainly for travel, when battery life actually is important.

In the measurements above I did not include hibernation, because FC35 does not enable that by default, so if I can get acceptable results without it, I’d rather not go through the hassle of enabling it.

13 Likes

@nrp Is this something y’all might be willing to comment on? Is it a known issue that y’all think might be fixable?

For the most part, I’m trying to figure out whether to wait and hold out hope for a fix, or to just bite the bullet and start using hibernation instead of suspend. The issue is bad enough that I can’t just close the lid of my laptop and put it down wherever. Because it’s very likely that the next time I come back to it, it will be dead.

6 Likes

Hello there!

I received my framework a couple weeks ago and I noticed the same thing, that high battery drain. I have followed this page to investigate. It looks like during s2idle the system spend only 50% of its time in C10 according to this command :

turbostat --show Pkg%pc2,Pkg%pc3,Pkg%pc6,Pkg%pc7,Pkg%pc8,Pkg%pc9,Pk%pc10,SYS%LPI rtcwake -m freeze -s 60

I made a few tests and came to almost the same conclusion as @Nils : the HDMI expansion card is responsible for this. Just unplugging it make the system stay in C10 95% of the time which solves the battery drain and the heat issue I have.

For science, here are my numbers:

With HDMI card

61.493130 sec
Pkg%pc2	Pkg%pc3	Pkg%pc6	Pkg%pc7	Pkg%pc8	Pkg%pc9	Pk%pc10	SYS%LPI
1.56	38.90	0.00	0.05	0.00	0.37	58.76	58.20
1.56	38.90	0.00	0.05	0.00	0.37	58.77	58.20

Without HDMI card

61.982575 sec
Pkg%pc2	Pkg%pc3	Pkg%pc6	Pkg%pc7	Pkg%pc8	Pkg%pc9	Pk%pc10	SYS%LPI
1.58	0.84	0.00	0.10	0.02	0.33	96.58	95.18
1.58	0.84	0.00	0.10	0.02	0.33	96.59	95.18

There might be a bug in the bios or the card’s firmware itself. Where can we report this so that Framework’s staff can have a look at it?

7 Likes

Hi @Daouadi_Philippe

I tried this on my new framework (delivered yesterday). Linux flavor:

Linux <redacted> 5.13.0-39-generic #44~20.04.1-Ubuntu SMP Thu Mar 24 16:43:35 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Even with both the HDMI and the USB-A connected, the stats are as below:

With HDMI and USB-A cards:
61.556127 sec
Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 SYS%LPI
0.48    4.87    0.00    0.00    0.00    0.00    91.65   91.44
0.48    4.87    0.00    0.00    0.00    0.00    91.64   91.43

Without HDMI card, with USB-A card:
62.126707 sec
Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 SYS%LPI
0.53    0.35    0.00    0.00    0.00    0.00    96.73   96.02
0.53    0.35    0.00    0.00    0.00    0.00    96.73   96.02

with HDMI card, without USB-A card:
61.769479 sec
Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 SYS%LPI
0.48    4.94    0.00    0.00    0.00    0.00    90.53   90.34
0.48    4.94    0.00    0.00    0.00    0.00    90.53   90.34

Seems clear that the HDMI card is the suspect. I also closed the laptop lid overnight and observed battery drain (~8 hours) with the HDMI card connected, and observed a 29% drain from a full charge.

I will be continuing to assess this and try out other solutions over the next few days. We do need to get this to the attention of the Framework staff.

I re-did the overnight experiment with the HDMI expansion card removed, and now there’s only a 16% battery drain in 8 hours. The HDMI expansion card seems to be responsible for almost half the power drain in suspend.

1 Like

Maybe I’m just old, but I am not understanding why you guys are leaving your laptop on all the time like this. If you are going to be leaving your laptop unused for 8+ hours and it’s not plugged in, why wouldn’t you just shut it off?

Power off battery drain 8 hours = 0%

1 Like

I’m old too. I’ve been doing this kind of thing with laptops for years. I just close the lid, it goes to suspend and I can open it several days later with mimimal drain and pick back up right where I left off.

The Framework is the first laptop I’ve had where I cannot do this any more. I either need to power it off (and indeed, sometimes I do that) or plug it in. (Or switch to hibernation, which is slower.)

Age has literally nothing to do with this. You have your workflow and I have mine. :slight_smile:

I think it’s best if we keep this thread to the actual issue rather than suggesting we ignore it and change our workflow. Changing my workflow is already what I’m doing. The point is that I would prefer not to.

7 Likes

@Andrew_Gallant

I am also experimenting with the deep-sleep and hibernation suggestions in Linux deep sleep

Will keep this thread posted with the results.

Did you consider these options? Do any work for you?

I’m already using deep-sleep. I mentioned hibernation in a previous reply.

2 Likes

I use deep sleep and it’s not enough, so I’ve switched to using both by making systemd hibernate after a few hours.

I wish I didn’t even have to use deep sleep, because it takes like 10 seconds to get back into my system after opening the lid.

My old X1 Yoga woke instantly and lasted forever in sleep. I like my Framework, but this is definitely the worst aspect.

3 Likes

Because getting back to your workflow could take minutes (more time), than seconds. e.g. Various 2FAs to log into, starting apps with specific projects where you left off, certain project states…etc

3 Likes

:unamused:

Best practice is to shut down your laptop if you aren’t going to be using your laptop all day. It’s better for the machine, and with the speed of SSDs these days there is really nothing to it. With all the grief this suspend mode battery life issue seems to be causing I just thought I’d mention it.

Taking a couple minutes to set your workflow back up seems like a very minor inconvenience. Honestly, neglecting to properly shut down your computer if you aren’t going to be using it seems more like laziness than a legitimate workflow aide.

2 Likes

Where’s that line drawn between 30 minutes, 2 hours, 4 hours, 5.5 hours…?

In what sense is it better?

Having the right tool doing the right thing is all about laziness. Having computers…is all about laziness. I would hate to walk over (using a car is lazy, right?) to Blockbuster to rent a video. Why do something that can be automated or have a shortcut?

Suspend IS a feature. It’s just really poorly implemented (by Intel?).

I mean, OMG, it’s a feature that’s been a feature for 25+ years… And ‘laziness’ is all you got to say about not to use it? You have issues.

You seem to be mixing up “unused duration” with “needing a resume state”. People need a resume-able state, regardless of the unused duration. The ‘choice’ between making use of a power off state, vs a resume-able state is a personal choice. Who are you to judge on someone else’s usage decision?

You are a person, a parent. Respect the other person’s choices and don’t overstep your authority. (This is a return for your overstepped judgement. Should you not have done so, this wouldn’t need to be said.)

8 Likes