@m0biusace got 320 and 306 mW. Seems like ~0.6%/hr drain without the USB-A or HDMI cards is pretty repeatable.
2 Likes
The battery icon in the Taskbar has all the control. I scratched my head as well… Looking at the settings menus.
Yes, 8GB x2 3200mhz 20char
1 Like
A third reinstall of the drivers finally installed the SST driver and over a ~4 hour period it went from 55% down to 46%. I wouldn’t call it the greatest sleep, but it’s better than what I had. Thanks for the advice about trying a 3rd time.
The sleep study finally showed sleep with the discharge. I’ll test it again tomorrow to see if this was a fluke.
I got the SST driver on the first try. But I’ve been keeping my other Intel drivers up to date with the Intel Driver and Support Assistant, which I highly recommend if you do any gaming (even light gaming) on the Framework because it gets new graphics drivers earlier than Windows Update does.
1 Like
I’m not sure how people are getting over 2 hours per 5% battery drained.
With only USB-C cards plugged in and the super low-power SK Hynix P31 Gold, I can’t get over 2 hours. Any ideas? I’ve already disabled network connectivity.
1 Like
I’m having a similar problem with standby not working as expected, instead switching to hibernate after about an hour.
In my case the issue doesn’t seem related to sound, but instead from the SoC subsystem - NoHwDrips.C2-C9, but I’m not really able to figure out what those subsystems are. Does anyone know what these are, or how to find any references to them? Any help would be appreciated.
I should add that it’s a batch 3 diy unit, with the 3.02 bios (I believe), and the beta driver package 2021_08_31.
1 Like
I’m curious though if this is caused by certain conflicts in hardware (ie an SK Hynix P31 Gold vs Samsung 980 Pro vs my Adata XPG 8200 Pro ssd), since some of the posts above don’t show the same issues once the sound driver was updated.
I’m also curious if there’s any way to actually identify what that different C#s are. I see it’s all part of the SoC, but does the SoC have a standard naming convention that maps to specific components - such as C1 is cpu, C2 is gpu, C3 is memory, C4 is I/O, etc? Similarly is there a reference on what something like CTA_DEVICE_BLOCK is?
1 Like
I’m no Kieran, and that’s for sure, but I would say that based on the reports we have in this thread, C10 seems like it would be part of the USB controller / Thunderbolt controller. I say that because as soon as the modules are removed with the exception of the USB C passthrough, power during standby seems to sky rocket. Someone here got 8 hours of standby before hibernation.
The C states refer to how deeply powered off various cores and subsystems on the SOC are.
For example C0 means cores are fully powered on with clocks running, and then as you go higher and higher in the C states, the cores get clock gated, powered off, caches get flushed and powered off, etc.
As you progress to the higher C states, the latency to start executing code increases as it takes longer to power things up again, fill the caches from system memory, etc.
This article generally explains what the C states are at a high level:
If you want to imagine the complexity at a lower level the UEFI spec goes into a lot more detail, and this can get quite complicated as you may have multiple cores in different c states, and want to run a scheduler that predicts what the best C state to be in will be, I would imagine this is still an open topic of research in compE with all kinds of ML/AI being tried:
https://uefi.org/specs/ACPI/6.4/08_Processor_Configuration_and_Control/declaring-processors.html#cst-c-states
4 Likes
Luckily I’m not the only one on the boat here. Personally the only viable ‘solution’ at the moment is this:
Open gpedit.msc (Local Group Policy Editor)
Computer Configuration → Administrative Templates → System → Power Management → Sleep Settings → Specify the system hibernate timeout (on battery) - I set to 60 seconds, which basically means that after 60 seconds in sleep mode is goes to Hybernate. No proper sleep mode here, guys!
I’ll make a test with surface laptop 4 with tiger lake i7 to test how it discharges over night.
1 Like
Thanks for the details Kieran. I think I was thrown off by the sleep report and had convinced myself that the issues were from some component within the SoC, rather than something else keeping the chip in a higher C state.
If you need anyone to test anything, I’m happy to volunteer.
Just to confirm I’m having these same issues. My Framework drained the battery on a trip to a mall, went from ~75% to 3% in my backpack. Gonna switch it to just hibernate all the time until this is fixed.
I mean, I would suppose it didn’t. The odd part is that when I closed it, I’ve been checking to hear the fans shutting off and they do.
To add on to this, closing the laptop lid consistently causes the laptop to get very hot and the fans ramp up aggressively. My settings have the laptop sleeping once the lid is closed, but that doesn’t seem to work.
Same here.
Pretty sure that’s not the case, but ok.
I hope we do get a legit fix.
I upgraded to beta 3.03 and used the driver bundle in that same post but no dice.
This has happened to me before as well. I have it set to just hibernate when the lid is closed now. It only takes ~10 seconds to boot from hibernation which is fine for me since I don’t really close the lid unless I’m not going to use the laptop for a bit 
Guess it does stay in Screen Off for some reason… Why? It’s been doing it since the fresh install of Win11, and also does it on Fedora btw. I have no idea why it decides sometimes to Screen Off instead of Sleep. And even sleep mode just lasts half an hour
Since I got it.
I know, it’s still extremely high. My old X1 Carbon Gen2 lasts for a few days before it goes into hibernation. I’m just highlighting the fact that it does.
It also happens under Fedora 35, which I set up dual booting for.