Waking up on incoming messages
Scenario
People use an array of internet-connected applications, which typically stay online in order to give the user updates whenever something interesting is happening. E.g. email client should tell about new messages, VoIP app about incoming calls, weather application about the incoming tornado.
Problem
Responding to incoming events from the network means expending computational power. In the extreme case, the CPU wakes up on every network event, and is able to enter low power mode only very rarely, reducing time between charging.
Handling incoming events before they reach the phone CPU allows the CPU to sleep longer and save more energy, but becomes harder to implement.
Previous solutions
Quick wakeups
It was mentioned on Matrix that some phones can wake up very quickly from a low-power mode, process the incoming message, and go back to sleep if it's not important.
This is not viable with the Librem 5 hardware due to wake up times being slow compared to the number of network packets typically incoming (please confirm).
Remote infrastructure
The Android ecosystem moves the filtering of messages out to an external service called Firebase.
The benefit it provides is that it delivers only messages that warrant a wake up, eliminating the need to wake up to filter messages on the phone.
Disadvantages:
Applications must explicitly support it.
It's a centralized service, connected both to the user's device and the application's server (leaking user-application association), performing message filtering on behalf of the user (leaking message metadata or contents).
It needs to be hosted forever, for free, and reliably.
Keep connections open
Some applications choose no solution and just keep open connections. Android then warns about increased battery usage.
Brainstorming
Here are some ideas collected from the Matrix discussion on dev/librem-5-hardware
Unified Push
An open equivalent to Firebase, sharing most advantages/disadvantages. On top of that:
- multiple providers
- only supports Matrix
- can be self-hosted
Wake on Wan
Kernel issue: linux#21
Basic approach, here for completeness. Let the WiFi module/modem wake up the CPU on incoming packets.
Probably unfeasible given that lots of applications will keep open TCP connections all the time (especially the Web browser).
Use M4 core for filtering
The iMX8MQ chip has a low-power ARM core with access to all peripherals. It could be used to triage incoming packets without waking up the main CPU core. This would involve putting an IP stack on the M4 core, as well as a WiFi driver. Then, it would mean working with the kernel to inject the inspected packets back once the kernel wakes up.
The filtering would involve waking the CPU only when a matching packet arrives (e.g. based on host/port combination). It needs devising a way to identify important packets in the userspace and sending filtering rules down to the M4 module (possibly adding support to each application).
Unwrapping TLS encryption poses a difficulty here, as well as the application layer.
This requires lots of effort, and it's difficult to estimate the impact (possibly too many wake ups).
Use card firmware for filtering
Similar to above, except limited to network layer. Not waking on broadcasts, etc.
Don't wake up fully
This suggestion concerns speeding up the filtering inside an application. Instead of resuming from suspend with all the drivers, the kernel could wake up only the parts that are needed to check the incoming packet. If the packet does not warrant a wake, then kernel could quickly put the system back to sleep again.
Use something like suspend2idle
This should provide power savings and make wake ups fast.
Wake periodically
Let the main core wake up every once in a while (1 second to 10 minutes?), and process incoming messages then.
The advantage is that it's simple and easy to try.
The disadvantage is that waking up often increases responsiveness (including critical actions like receiving a call) but causes unneeded wake ups.