Yay, finally!
May I ask why a 15 minutes delay and not less? Why is it not automatically when you shut the screen?
You can still get notifications in that window.
This is great! Testing it now for a few hours…
I hope the follow up post will emphasize and confirm that L5 now becomes able to reliably be used a full 24h day and more (especially reliably get through the night and wake me up in the morning). This would be an huge improvement pushing it close to daily driver maturity level.
I agree, I wonder too why not shorter times, like 5 and 10 mins (how much would the impact be and where - downsides?) and why not straight from shutting the screen (as an option). Even more useful, if we’d get some “low power threshold” options, where at a set percentage user could have extra measures taken, like all network connections shut down, screen brightness minimized etc. to keep phone alive as long as possible.
Just a dumb question, in the article it only write about calls, I hope the wake up works for SMS/MMS and alarm clock too (for XMPP chat message, I don’t think it will works).
Article says:
While suspended, your phone won’t be actively running apps, but it will be listening for calls and text from the modem, which should wake up the device when needed.
So that covers SMS.
MMS? Good question. Alarm clock? Ditto.
Chat message or any other data, coming in via either WiFi or cellular? Good question.
Because it’s still an early preview and not all things have been configured as we want them to yet?
Same relates to that horribly long delay between the phone waking up and the modem registering an incoming event. That can be fixed, but nobody did it yet because we’re still busy with more fundamental things.
Hmmm… mixed results from testing. Here are my observations:
- The suspend engages at 15mins, as predicted. It shuts off also the notification LED, which I think should be visible to tell that messages have been received at some point.
- Call and SMS did wake the phone (lock screen appears so something happened) but did not make the modem visible/alive/ready (indicator icon does not appear for mobile network) and there is no notification (once the modem needed a reboot to reappear). Call goes to voicemail or is blocked (differed on what networks I used to test). Second call a few seconds later goes through. SMS doesn’t seem to arrive (arrived much later).
- Alarm does not wake the phone from suspend (using default clocks)
- While mobile (data off), wifi and BT on (but not used), power went from 99% to 87% in 130minutes while using suspend (after 15min). For comparison, without suspend for the same time idling, power went from 99% to 79%. This needs longer testing and other variations but indicates a good increase in idling time, maybe even around half more (very rough estimate and no optimization).
- A couple times the suspend did not wake up, effectively it had powered down. Needs a looong push of power button and then a normal one to boot.
Other notes regarding power saving:
- Shorter limit to suspend would be good, just to optimize it, including suspend after (manual) screen lock - plenty of options and variations
- Needs settings for user to set behavior rules at certain power levels (normal, low and critical come to mind) - user defined levels
- Power saving options have “mobile broadband” which is a bit confusing because the explanation text doesn’t fit to screen. What does it do (shuts down connection - even an active one? or powers down?) and especially when does it do that (same with wifi and BT) - can this limit be user controlled?
So, promising but not for daily use at the moment.
MMS works like SMS in this regard. I know that GNOME Clocks had some support for waking up from suspend being baked, but I’m not sure what its current status is.
IM messages - that’s an outright “no” until we get periodic wake ups to check for things like that.
Can I suspend the device somehow by my own. In the past I used
echo mem | sudo tee /sys/power/state
but this did not worked anymore. run it from the terminal and somehow the device was blocked with display on. I had to reboot it with long press of power button.
Suspended phone does not wake up on incoming call.
Would there be a way to wake up for a ssh connection?
No.
It’s still experimental and unstable on some devices.
How about a workaround possibility: call first to wake up (would this count as multi factor security feature?). Not elegant but if there is no other way. Maybe develop this idea to create a password requirement to establish ssh (script to open port for instance) for some actual 2FA (“dial 3 for ssh”, “dial passcode to enable ssh connections”).
IM messages - that’s an outright “no” until we get periodic wake ups to check for things like that.
…or even better: until we get an open source modem, which can run some notification service on its own.
I didn’t follow the development around the Pinephone modem recently, but it seemed they were getting there…
IM messages - that’s an outright “no” until we get periodic wake ups to check for things like that.
I completely understand the reasons for this, but it isn’t great for a phone that was intended to be Matrix-powered. If I understand right, periodic wake-ups aren’t going to work for catching incoming calls on any VOIP system (Matrix or otherwise). I’m happy to be corrected on this…
but it isn’t great
I perfectly understand that, and this is why we’re still very far from enabling suspend by default.
Obviously an exciting step forward. Of course I had to try it out. I think I saw one of the posts above answer this, but then someone asked the question again, so I’ll help re-answer. In my experience the only issue was that my morning alarm did not wake up the phone. It just told me later when I got up on my own that I had missed it.
So then I told my phone NO, YOU missed it. And then phone said, “Oh yeah?” And I said, “Yeah.”
But I had woken up anyway, so I still had to go to work.
I don’t know why the suspend needs to be so long. In terms of clock cycles of the CPU, this sounds like an eternity. What matters to save power isn’t the continuous off-duration, but the duty cycle of the on/off periods.
A series of events that need to happen upon wake should be established. Let’s say that a polling of fifty events needs to be checked upon every wake. If each event takes 1mS (1 mili-second) each, then checking 50 events takes 50 mS. That’s one twentyth of one second or 5% of one second of awake time. If the phone stays asleep for ten seconds each time before waking, then the phone is awake for only 0.5% (one half of one percent) of the time in such a duty cycle. So you could wake the phone every 10 seconds and increase the battery by several times over, in the process. You might even be able to do the same if waking up once every one or two seconds to save a lot of power.
Although my example may or may not be accurate, the concept should still apply. At GHz processing speeds, you can wake up, do a lot in a fraction of one second, and then go back to sleep for a majority of one second before waking up again. So why wait several minutes to wake the phone up?