> 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 3 hours ago | parent | next [-]

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.

	▲	3 hours ago \| parent [-]
		[deleted]

▲

maverwa 13 hours ago | parent | prev | next [-]

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 4 hours ago \| parent [-]
		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.

▲

N-Krause 14 hours ago | parent | prev [-]

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 6 hours ago | parent | next [-]

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 4 hours ago | parent | prev [-]

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.

	▲	valleyer 15 minutes ago \| parent [-]
		> 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.