markqvist
High battery drain with Sideband in background
Describe the Bug Sideband on Android is using a lot of battery in background.
See the screenshot below.
To Reproduce I cannot say for sure if this is reproducible, but under "Connectivity" I only activated the "Connect via local WiFi/Ethernet" option.
Expected Behavior Sideband should not drain that much battery in background. This forces me to either disable background activity completely or to delete the app.
Logs & Screenshots
System Information Phone: Pixel 8 Pro OS: Android 16 (BP2A.250805.005) Sideband APK version: 1.7.0
Additional context
Following; I have the same issue. I'm on a Google Pixel 6a, and the battery usage is insane.
I have the local wifi/Ethernet enabled as well as several custom TCP endpoints. Transport is disabled.
Edit: some initial testing suggests that it may actually be the local wifi/eth which is eating up the battery. I'll get back with more data later. Keeping the TCP endpoints up seems fine.
Update: I can largely confirm that the local Ethernet/wifi option is the worst offender for power consumption. Similarly, if you have TCP/I2P links and you have poor signal (I.e. you're using 5G in a concrete bunker) your phone will crank up the radio tx power, which burns a fair bit of juice to maintain the socket connection.
I think there are some improvements to be made on the efficiency of the local eth/wifi connection option. I'm less sure about what can be done about general TCP connection efficiency.
For me, having an rnode connected absolutely murdered the battery. Used about 50% in a matter of few hours -- even with no actual activity.
I have the same issue!
Just running a local wifi interface and a TCP interface, point to a lan address.
My battery is draining like a river. 😂
Using a Xiaomi Note 12 Pro.
The power drain issues will vary from device to device, and unfortunately there's now way to "solve" this universally, as it is really a device-dependent hardware issue. I've posted about this before in the discussions and such, but for visibility it makes sense to have it here as well:
Sideband Power Consumption & Energy Efficiency On Android
On Android, device manufacturers need to find a way to avoid power-hungry chipsets draining batteries in just a few hours, which is why the Android OS will shut down more or less anything that is not explicitly in use as soon as the user looks the other way. This includes the network card and CPU. Obviously, running a networking stack means that the actual networking hardware is accessible to the stack, and this is no different with Reticulum. If the device needs to be reachable, it needs to be able to actually receive packets, and for this to happen, the networking hardware needs to be kept on and in a receiving state.
Unfortunately, many device manufacturers cheap out and use WiFi and/or Bluetooth hardware that is not very suitable for mobile devices, with quite high power drains, and sub-par energy efficiency. Device manufacturers compensate for this by keeping the WiFi off, in sleep state, or by disabling "power hungry" functions such as multicast most of the time.
This is all annoying, and the world would be great if everyone just used more efficient WiFi hardware in their devices, but of course that's not the reality. So on Android, Sideband asks the operating system to acquire WiFi and multicast locks, which will keep the WiFi hardware in a state that can actually receive traffic, even while the screen is off. Unfortunately, on some devices, this incurs a significant additional power drain. On some devices, it's barely noticeable. Either way, there's not really any way around it, if one wants to have persistent end-to-end connectivity that doesn't disappear as soon as the device screen is turned off.
To be able to process incoming messages and events in the background without significant delay, Sideband also acquires a CPU lock. If it did not do this, processing for the background service would be paused and unpaused randomly, and only available for short intervals of time. Needless to say, message delivery would be incredibly unreliable in this case.
Here again, we find the same problem. Some device manufacturers use chipsets that are exceedingly power hungry, even when they are not really doing much. The actual Sideband background service is really quite efficient, and has a very low CPU and memory load, and is not doing any actual work when there's no work to do. But that doesn't help if the device it's running on keeps the CPU clocked at 1.8GHz all the time. This (in possible combination with the WiFi and/or Bluetooth hardware) is the power drain is coming from.
In general, it's an unfortunate reality that's rooted in the very deep-seated paradigm of "servers" handling everything, with user devices being simple thin-clients to centralised infrastructure. Sideband tries to mitigate as best as possible. But because this paradigm is so ingrained, it leads to a lot of choices, down to the hardware level, that make real end-to-end communications systems difficult to achieve.
That there is even a way to get something like Sideband and Reticulum to work on such a limited platform as Android is really a bit of a miracle :P
Hope the above makes things a bit more clear. I know it's a complicated topic, but I couldn't really boil it down to anything more concise than the above.
Also, just to contextualise the above, most mobile "instant" messaging systems don't actually deliver any messages to you. They deliver the message to a server on the internet, and that server then sets a flag that the notification subsystem of the kernel of your device can then poll (in a scheduled, batched, power-efficient way) to discover that there is a message waiting for you, which then results in the device waking up it's hardware for a short amount of time to establish a TCP connection to the remote server, download the message and then go back to sleep.
The whole idea of the message actually being sent to you is nothing but an illusion smacked on top of the centralised server paradigm.
Sideband does not do this, messages are actually delivered directly from end to end, from one device to the other without them ever touching an intermediary server. And one some devices, this does incur extra power consumption. On other devices, with more efficient hardware, the extra load is barely noticable.
As an example: On a Pixel 6 Pro running GrapheneOS, neither WiFi, Bluetooth nor TCP-based interfaces add any significant power drain. On a cheap e-ink tablet, keeping the WiFi on drains the battery in 4-5 hours. On another old Samsung phone I tested with, using Bluetooth was a significant power drain, while everything else was fine.
So unfortunately, there's not a one-size-fits-all solution to this. On some devices, it will be the WiFi hardware being the main culprit, on others it will be Bluetooth. On some keeping a TCP interface open will be expensive, while using the raw WiFi interface or Bluetooth will be the most efficient. You will have to experiment with what works best on your device.
Closing as there is not really much we can do to improve this, other than user awareness.
Isn't closing this achieving exactly the opposite as user awareness?
there is not really much we can do to improve this
Without a root cause analysis, you can't tell. I believe the battery drain is not caused by something that can't be fixed. Buy a detailed analysis is required.
It's not an "issue" I can "fix", so it doesn't belong on the issue tracker as an open issue. It's not like closing it makes it invisible to people or un-searchable. I can't really do much more "detailed analysis" than what I've already done here, but if you have any insights to add I'd love to hear them.
I've added comments regarding Android power consumption to this relevant discussion thread:
- https://github.com/markqvist/Reticulum/discussions/963
In addition, it has been brought up several times before, and explained several times before.