[jeffbee]

> If you can’t hibernate (aka suspend to disk) you will never be able to get that power consumption low.

This is cope. An Apple Silicon Macbook does not need to suspend to block devices to save energy (they only do this when the battery is empty). ChromeOS doesn't offer hibernate at all. The only reason that a Framework can't have good battery life in an operating state is that nobody is paying attention to the details.

[hackyhacky]

Correct. I've got a ThinkPad T480s. Hibernation is disabled, but suspend works great. Keeps charge for at least a week. Running recent Debian. I think that Lenovo, for all their faults, just does better with Linux than Framework.

[maverwa]

Thanks, I did not knew that. My understanding was that keeping the memory alive for suspend-to-idle was the main issue here. But that also might be something a vertically integrated Apple Silicon can win vs. that x86 madness there every day.

And to be sure, I do not claim that there is nothing to gain in s2idle. I bet theres still a lot of headroom to safe energy. Its just that it would be easy to safe a lot of power if s2disk "just worked".

[heavyset_go]

Keeping memory alive is how sleep worked for over a decade and is incredibly power efficient.

The issue is that Modern Standby goes ones step further and keeps the CPU and peripherals in low power states instead of just the memory. This will use more power than S3 sleep by default, and each SoC will need deep integration with the kernel for that to ever be power efficient. That means it will require heavy investment from AMD and Intel to enable efficient Modern Standby in Linux, along with heavy vendor investment to ensure each model they sell implements Modern Standby efficiently.

It isn't a matter of Framework dropping the ball, it's matter of hardware platforms being shitty and platform owners not investing as much resources into Linux as they do Windows.

[trinsic2]

I dunno man Windows is pretty bad with drain in modern stand by too.

[N-Krause]

And what are those details? Sounds like you know specifics that I'd like to also know.

If you're claiming it is just an oversight, then please back it up.

[nagisa]

While I don't have any suggestions on how to look at the relevant metrics, a big part of the issue is the parts selection and having them power off properly.

1%/h is just 0.5W (for a 50Wh battery) which isn't a lot, but fail to bring a component or two to shutdown or sufficiently low power state and you'll observe exactly this behaviour. Of course some drain is going to be almost inevitable just to keep memory contents sufficiently refreshed, but with proper power-saving states memory can go appreciably below 0.5W.

[chongli]

Timer coalescing, idle wakeup minimization, race-to-idle optimization, etc.

It's not a single oversight, it's a massive project that needs to be carried out throughout an operating system. Linux's usual advantage of decentralization and wide distro variety with massive customization potential is a disadvantage here. To have a power-efficient system you need all of the software to be working toward the same goal. One bad actor process can completely hose the system's power efficiency.

[AnthonyMouse]

> Linux's usual advantage of decentralization and wide distro variety with massive customization potential is a disadvantage here.

How so? You need each thing to do its part, but that decentralizes perfectly well because it isn't actually integration at all, it's just a hundred different pieces each doing it right.

And open source has the further advantage that you're not beholden to the maintainer. If Framework notices that piece #37 is wasting power, they have the code and can fix it themselves. If the upstream isn't completely asleep at the switch they'll accept the patch, and even if they are you can still ship it on your own device.

Where this can get messed up is in one of two ways. The first is if something is not open source and then the vendor fails to fix it but also fails to supply anyone else with the capacity to fix it. But this isn't a problem with integration, it's a problem with filthy knuckleheads not keeping their heads on straight and calls for some new competitors to show them how to do it.

The second is something like an actual trade off, e.g. if you want the machine to be able to wake via network packet or pressing a key on the keyboard then you'd need the network controller or USB controller to stay in a low power state instead of being dead off. And then that might cost you half a watt, but you're paying it in order to get something, and then somebody has to decide if Linux users would typically want a default where that feature works or one where the battery can last a month in standby, since it's one or the other.

[chongli]

You’re right that it’s “a hundred different pieces each doing it right” but you gloss over the disadvantage of decentralization: getting everybody on board with the project. With a centralized product (such as at Apple) the CEO can say “I want to increase battery life on existing hardware by 20% before next release or you’re fired” and people will work 80 hours a week to get that done. With open source? You’ve got ten thousand different projects, each with their own leadership and their own priorities. You have no leverage at all to get them all to work on power efficiency, so naturally it takes a back seat to them working on their favourite features.

[AnthonyMouse]

Because it's not actually a disadvantage, because if it's actually open source no one can stop anyone else from doing it. If you or your company wants to work 80 hour weeks to improve power efficiency on Linux, you can submit patches to all the different projects where nobody else is doing the work.

And that actually happens in real life. Most of the projects care to begin with because they use their own stuff and don't want to ruin their own battery life or have a competitive disadvantage over the alternative. Then other third parties that find business value in having it work pay someone to clean up the odd stragglers when one of them didn't do it or have the resources to do it themselves.

The main problem is when some vendor both doesn't do it and is hostile to anyone else doing it.

[chongli]

And that actually happens in real life. Most of the projects care to begin with because they use their own stuff and don't want to ruin their own battery life or have a competitive disadvantage over the alternative.

Sure, they try not to ruin the battery life, but who is investing the amount of engineering resources into Linux battery life that Apple invests into macOS's? No one, of course, because the ROI of doing that for Apple is much higher than doing the same for Linux. Linux's open nature means that going for SotA battery life does not yield a competitive advantage, so no one does it.

If you or your company wants to work 80 hour weeks to improve power efficiency on Linux, you can submit patches to all the different projects where nobody else is doing the work.

In other words, centralize the battery life project. Who is doing that?

[valleyer]

> Timer coalescing, idle wakeup minimization, race-to-idle optimization

These are important things, but they do not matter for power consumption in sleep, when the CPU is not executing instructions.

[chongli]

That's a hardware issue.

[jes5199]

and yet my M1 manages to drain the battery in suspend mode in just a few hours

[maleldil]

Something's wrong. Maybe a setting or a random app is preventing your laptop from sleeping properly. You have many threads here saying that MacBooks can go weeks on sleep, and that's also my experience (M1 Pro).

[vladvasiliu]

There was a thread about just this issue another day.

I don't daily drive an MBP anymore, only occasionally. But I had one for a week or so, and once or twice I've noticed that my backlit keyboard still had its lights on, which is unusual when the computer sleeps. The screen was dark, though, so it can be confusing.

[rikkert]

Let me guess, you use docker?