The wake timer could be the issue, but it is not the sole issue as far as standby being interrupted because of Windows goes. If you have audio playing or if an audio application is even open it can poll the device preventing standby. (To be clear this is a Windows issue and not a Framework issue.)
But if you closed the lid and the device really drained to 0, something else happened, and I would ask what applications you had open. Something interfered.
I’m glad to see the work happening on this, and it looks like progress has been made. But the Framework will never be able to match the battery life of a Tiger Lake system that uses LPDDR4x memory, which uses substantially less power than the DDR4 in the Framework. That is a tradeoff that we have to accept for now to get user expansion, repair, and upgrades. There is no socketed form of LPDDR4x; it has to be soldered onto the motherboard.
Perhaps the industry will see fit to produce a socketed form of the next generation of ultra low power RAM, so that a future Framework will not be at a disadvantage.
Agreed, but at the very least the drain in modern standby by having any other expansion cards other than USB-C plugged in needs to be fixed as it essentially forces you to choose between a core feature of the laptop (choose your own ports!) and the ability to pause and resume work.
This has been with a clean install of windows. The only thing running was Edge with the community page open in one tab and the sleep report in another.
There were no audio programs running. During these tests, I had the power cord disconnected.
As an additional test, I left it plugged in overnight. This morning I found it with fans spinning to full and on a UEFI screen saying no boot device detected. This is very worrying as it had been put to ‘sleep’ by closing the lid.
I have not changed anything. I fresh installed Windows. Then installed the driver pack and tested the sleep. I had seen these posts about sleep issues and wanted to make sure my setup was not affected before I tried using it for daily use.
One thing to note is that I only see one power plan. In other posts on the forum I see people post that the framework driver bundle installed two power plans, but I don’t see that.
Removing my USB-A and HDMI expansion cards and disabling Bluetooth got me up to 8 hours and 43 minutes of sleep. This is a pre-assembled Batch 1 base model. I haven’t updated any drivers yet.
@m0biusace got 320 and 306 mW. Seems like ~0.6%/hr drain without the USB-A or HDMI cards is pretty repeatable.
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
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.
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.
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’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?
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
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.
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.
