Why don't laptops have proper low power states where useful stuff like downloads can run during sleep/with the lid closed?
Why don't laptops have proper low power states where useful stuff like downloads can run during sleep/with the lid closed?
Basically every laptop I've owned I've had to disable sleep when the lid is closed as I often leave them plugged in and want background tasks like downloads or updates to be able to run while I'm not using the machine. However, I don't think PC laptops have a way to switch to a super low power state and just run background tasks like downloads, alarms and notifications or running scheduled tasks without just being left on in regular power mode. Why is this not just a default feature of laptops, given that phones and tablets have been doing this kind of thing for the last decade or more?
Does anyone know if there are plans to make power management for laptops allow for running certain tasks in Windows or Linux in the future? My smug Apple using friend tells me his Macbook already does this, but is the lack of this feature on PCs software related or something innate to x86 vs ARM architecture?
You're viewing a single thread.
Why don't laptops have proper low power states
Actually, they do, it's called the "S0" low power state, and it's part of the ACPI standard. Microsoft calls this "Modern Standby" in Windows (and "suspend to idle" in Linux) , and it's pitched to do exactly what you've described.
The only problem is, the implementation sucks. Most users actually hate the S0 state because it consumes so much power - on some laptops, even the fans may continue to run on S0, and your laptop may overheat if you've closed the lid and chucked it in a bag, and it's in the S0 state.
Also, because Microsoft and Intel have been pushing this so much, the "standby" mode now defaults to S0 instead of S3 (which is full suspend-to-RAM). So many users actually actively seek to disable S0 and go back to proper S3 standby, via registry hacks etc.
So why is S0 so bad? Part of this is due to the limitations, long history and the variable nature of the x86 platform. All the power-saving stuff was implemented as an after-thought - both at the hardware and software levels. Whereas ARM, at least the modern ARM ecosystem, was developed with mobile usage and power saving from ground up. An x86 PC is also made up of components from disjointed manufacturers, and we need all those components to implement the same standards so that it all works well as expected. So for instance, if a particular component isn't capable of entering a low-power or active standby state, then it won't - and you can't do much about that, unless you're Apple and have a tight control over the ecosystem.
The second half of the problem comes with the software. All applications must be modern standby / S0 aware, if not, one of two things will happen: that app will keep the system awake, or the app will get suspended by the Desktop Activity Moderator (DAM). Either way, the app must be capable of running in the DRIPS phase (deepest idle runtime platform state), which rules out most Win32 apps (basically almost every app that's not on the Microsoft Store).
Finally, the reality is that most PC users don't care about modern standby regardless - and why should they, when they've all got smartphones, which handles notifications well? Also, hardly anyone does large file downloads these days, and the people who do still download, wouldn't care about doing it while on battery (and if they do, they can take manual actions to lower the power consumption, such as switching to a power saving plan and turning off the display etc).
Ultimately, most people would expect a laptop to go into a fully suspended state when the lid so closed and they're on battery, because if they're on battery the #1 concern for them would be the battery life. So most people actively seek to disable S0 and see it as a hindrance.
Thanks for the excellent response.
I wonder if Valve will try to implement it in Steam OS for the Steam Deck's successor, as a lot of people complained about the lack of downloading while asleep after the Deck was launched. It would still need cooperation in hardware I assume, but they were able to get resuming games working, so it doesn't seem like an insurmountable problem if there is enough desire from both gamers and Valve.
I don't think this would need to wait for a successor. The problems are software, not hardware. They would need to have games and SteamUI get suspended but leave other processes running, might be tricky and prone to bugs.
The problems are software, not hardware.
Of course hardware is part of the problem too.
PC architecture does not allow, for example, that the network interface may feed any data directly to the harddisk. Every bit and byte must be input to the CPU and then output from there.
Otherwise we could allow the CPU some real good sleep while other devices remain a little active.
Isn't this the idea of having a chipset (Northbridge/Southbridge) on the board, to handle some of these IO tasks?
Also, I recently saw the Cathode Ray Dude video on Dell's Brain Slug, where down basically hijacked the system with a low-power ARM SBC. I almost wonder if something like this would be possible, it would obviously require a revision but it would theoretically allow for suspended downloads, invite notifications, etc. It would also be fairly expensive and complex though
Isn't this the idea of having a chipset (Northbridge/Southbridge) on the board, to handle some of these IO tasks?
Well, not in the way we are talking here. The bridges work under the CPU's direct commands. When the CPU goes to sleep, they have nothing to do either.
Maybe a PC's CPU can do some short time limited sleep like microcontrollers do, and maybe that would be useful for such scenario's. But even then the main problem remains that the CPU wants to be in control of everything.
and the people who do still download, wouldn’t care about doing it while on battery
Very much this; I've got a whole army of machines I can SSH into to launch a long-running download, which frequently additionaly cuts out a 2nd step of copying the file to where it needs to be after downloading it (a action which would normally cause additional battery usage on the laptop).
And I thoroughly agree with you; I want the laptop to go to S3 sleep immediately when I shut the lid, and then pull it out of my bag a hours later with only a couple of percent of the battery consumed in the interim.
Thankyou for answering some historical mysteries for me. It has always irritated me that I didn't know why programs only sometimes drained battery while asleep - but it wasn't always like that, and I couldn't find a pattern in what programs affected it, and I didn't know why a Linux dual-boot on the same drive didn't cause the same issue. The backstory of this makes a whole lot of experiences make sense now.
What is involved in an app being S0 aware and running on DRIPS? Is this a badly-educated-developers-requiring-permanent-network-connections issue or a Microsoft-proprietary-certificate-bullshit thing or something completely different? I'm mostly curious for if I ever dive into desktop application development what performance optimisations I should be keeping in the back of my mind.
I haven't developed a desktop app in ages so I'm probably not the best person to ask this, but my understanding is that if you develop a modern UWP app, then it's automatically S0 aware, but you can also make use of WinRT APIs to execute background tasks during modern standby. The user can also choose whether or not to allow this activity.
I'm not sure if the WinRT APIs can be called from a regular Win32 app though. For Win32 apps, as far as I'm aware, they should get suspended by the DAM automatically (and background services may get throttled), but Windows may choose to unsuspend/unthrottle these apps if it thinks some critical activities are happening. I never looked into what it deems as a "critical activity". Personally though I always disable S0 so that my laptop suspends as you'd expect it to.
Bottomline is, if you're making a UWP app it should all just automatically work, maybe look into the WinRT APIs, and if you're making a Win32 app you need to look more into the DAM. There's some info on that here: https://learn.microsoft.com/en-us/windows/win32/w8cookbook/desktop-activity-moderator
Thanks so much, this is extremely helpful. I've been separate from the entire Windows ecosystem for a long while, so a high level overview like this is perfect. I now have all the acronyms and names I need to research further instead of trying to figure out what acronym is responsible for what, which is always the most tedious part.
Very informative- thank you