Power Usage of devices

[magdesign]

Lets share data of how much Watt devices suck running reticulum, sideband.

(did i miss anthing?)

Values taken from comments in this thread and useres in Matrix channel:

RNS

Brand	Model	BT/WIFI	Power draw/Scrn on)	Notes	User
Helltec	v3	off/off	~800 mW / ~850 mW		@kujeger
RAK4631	19003	off/off	~125 mW		@kujeger
RPi	zero2w	off/off	~400mW	alpine running rns	@kujeger

[magdesign]

if someone can share some methods of how to get this data.

for Android/Sideband:
Termux:
apk install termux-api jq
then run:

while :; do echo "$(termux-battery-status | jq -r '.current | fabs | round * 3.8 | round') mW"; sleep 5; done

(hope this code is correct)

close all other apps, disable the networks you dont need... hit a few times enter in termux before you turn off the screen to get a gap.
Its a bit difficult since screenbrightness and darkmode makes a massive difference...

[kujeger]

It might make more sense to just measure the difference of the power use with sideband off/on for phones? since they're unlikely to be doing only reticulum stuff, and so their power use will swing wildly

[magdesign]

thing is we cant meassure this in an unrooted android device.
remove the sideband table? or write down how many hours a device runs with sideband on?

[kujeger]

Lets share data of how much Watt devices suck running reticulum, sideband.

(did i miss anthing?)

Values taken from comments in this thread and useres in Matrix channel:

RNS

Should be noted that rnodes do not use wifi except when acting as a Bootstrap Console, at which point it isn't acting as an rnode. So all rnodes are always wifi off; the RAK4631 (and all nRF based devices afaik) do not have wifi hardware at all.

e: might be useful to show who contributed the numbers as well, in case of questions etc :)

[kujeger]

Did some more idle testing on my rpi zero 2w:
bluetooth and wifi enabled but not connected: ~420 mW
bluetooth and wifi enabled, wifi connected to network: ~530 mW
(otherwise identical setup as my previous measurement)

[markqvist]

Adding some comments here about Sideband power consumption on Android devices, relating to chipsets, WiFi/Bluetooth hardware, etc.

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.