rns.recipes

Hi folks,

I've been trying hard to optimise battery performance of a mobile client (Columba specifically, but I believe this is relevant to any mobile client), being mostly concerned about performance on cellular data.

I tried a few things, but the most effective ones turned out to be:

1. Using an AP mode backbone interface when on cellular. (The docs mention LoRa transport nodes as the featured use-case for AP mode, but I believe this is a valid use-case too.)
2. Increasing the tcp keepalive interval of the interface from 2 seconds to 5 minutes. (This is what Conversations, the xmpp app, does and it shows stellar battery performance without relying on push notifications.)

This way the cellular radio can sleep for longer periods resulting in much lower discharge rate: ~7-10x more.

The TCP keepalive intervals are unfortunately hardcoded in the RNS interfaces, so I had to roll a custom interface that basically extends BackboneInterface and does a couple of overrides to make the keepalive options configurable.

My questions:
a. Does this setup make sense or am I missing some considerations?
b. Do you think there's merit in making keepalive options configurable upstream and pleading with node ops to adjust configs? (or better update defaults upstream.)

All other performance battery optimizations seem futile: how well you manage wakelocks doesn't matter, if you want to maintain persistent connection and that connection is keeping the most power hungry component, the radio, awake.

Thanks in advance.

One of the foundational problems here is that Columba turns on Transport by default for every installation.

That means that every person's phone, tablet, and so on, is routing traffic, processing announces and path requests, and generally using a lot of CPU cycles, bandwidth and battery on things that:

• Don't actually help the network
• Doesn't benefit the user of the app

The reasons you're seeing improvements with AP mode is that it's limiting announce transport processing significantly. But in reality, transport should have been off to begin with.

I've advised the developer of Columba against this approach a couple of times (both on privately, and on the Columba github repo), and specifically mentioned this would be bad for battery life.

If you increase the keepalive interval to 5 minutes, would you like to wait 5 minutes before RNS can detect that a TCP connection is broken, mark the interface as down, and find another path?

In normal circumstances, sending a keepalive every few seconds will use practically no energy. It's a few bytes only. The radio is kept awake anyway, there's not really any way around that if you want to be connected to the network without Google's "services" "helping" us out.

Some devices have really power-hungry WiFi/BT chipsets, some don't. Cheaper devices will often have horrible power consumption when the radio is kept awake, but then again, I've seen cheap phones with excellent chipsets that use very little power, even when kept awake.

A good radio chipset will have neglible impact on battery life, even if awake, a bad one will drain it very fast.

There's no magic bullet here, unfortunately. It varies wildly by device type and model.

But really, most of it in this particular case is probably coming from:

• Having transport turned on by default
• Now routing announces, path-requests and traffic 24/7 from your pocket

This is not the intended default user configuration, and doing it like that is a broken way of doing it.

Just as a reference, I'm using Sideband on my own device, have it running in the background 24/7, connected to 5 different backbone remotes, plus auto-interface on WiFi, plus RNode on standby on BT, so it connects as soon as the RNode is turned on, and I get around 2-3 days of standby time.

It's not RNS eating your battery, it's Columba.

Hi Mark! I was worried after you didn't reply to my DMs last week, after you last asked if I had disabled transport by default in Columba, that you might not have received my messages. Quite relieved that this seems to have been the case!

Rest assured, transport has been disabled by default in Columba since https://github.com/torlando-tech/columba/pull/777 (first released in v1.0.0-beta), where you can see that someone actually complained that I disabled it by default (despite it still being an option). While this doesn't change the setting for existing users, v1.0.0-beta also installs as a separate app (new application ID) so effectively everyone is a new user. I have also buried the option under an Advanced section at the bottom of Settings, with a more verbose warning explaining the tradeoffs of enabling Transport on a mobile device.

Hi Mark, thanks for replying and for your reference on battery performance.

One of the foundational problems here is that Columba turns on Transport by default for every installation.

I believe this is no longer the case. I certainly didn't have it enabled by default when I first installed columba a few weeks ago.

The reasons you're seeing improvements with AP mode is that it's limiting announce transport processing significantly. But in reality, transport should have been off to begin with.

Yes, I read the docs and that's why I chose AP mode. But again I don't have the transport enabled.

My reference device is Pixel 7a. Two of them, and both are showing the same battery performance. I've tested Sideband a while ago and Ratspeak recently, and the battery performance numbers are similar to Columba. Could it be an issue with my carrier? I'll do some more tests.

About your reference, would you be willing to share your device model? 🙏

oh, forgot to respond to these points:

If you increase the keepalive interval to 5 minutes, would you like to wait 5 minutes before RNS can detect that a TCP connection is broken, mark the interface as down, and find another path?

Yes, I wondered about this, and, just as one thought, it could be left to clients to be adaptive here: if connection breaks, back off and cut the keepalive interval in half accepting higher drain.

A good radio chipset will have neglible impact on battery life, even if awake, a bad one will drain it very fast.

I wasn't aware of that. But then this begs a question of inclusivity. I'd assume cheap devices with cheap radio chipsets are in the majority in the world.

@Rama: If transport is not enabled, AP mode will have no effect. That setting only affects code paths reachable when transport is enabled. So if it has an effect, that's a pretty good sign that transport is actually enabled.

The latest release of Sideband (1.9.4) includes RNS 1.2.5, which has several small fixes and improvements for weird edge-cases that were causing high battery drain; related Android OS internal TCP socket buffering when the UI part of the app was sleeping, and then some weird behavior on rmnet-type kernel interfaces (those are the carrier-specific uplinks). The device I discovered these quirks on was actually a friends Pixel 7a, so there's a chance that might help you out as well.

Take a look at the old power consumption / battery threads on the old github discussions, there's some good info in there as well.

Also, as a side-note, until the RNS 1.2.5 release, the network was massively spammed by broken and slopcoded LLM-ware, which spammed up to 100 path requests per second at some points. This would have caused a lot of unnecessary processing overhead on end-user devices.

I sat in front of my computer for more or less four days straight to implement reliable control mechanisms for situations like this, and it is now effectively blocked and managed by all nodes running RNS 1.2.5 and up, which should help quite a bit as well. But if you're still connecting to an entrypoint sending you hundreds of path requests and announces per second, it is going to drain the battery ;)

Hey Torlando
No, I didn't get those messages. Good to hear it's no longer enabled by default!

Thanks for the confirmation Mark. Seems my latest build that I replied with has a bug in the stamper path. Have it reproduced locally against Sideband, with stamp cost enabled and drop invalid stamps enabled. Same behavior: got a delivery proof on Columba, no message showed up on Sideband.

How embarrassing! :/ Oh well, I'll get it patched as soon as I can, and resend those dropped messages to you once it's fixed.

@Rama: If transport is not enabled, AP mode will have no effect. That setting only affects code paths reachable when transport is enabled. So if it has an effect, that's a pretty good sign that transport is actually enabled.

I meant that I added an AP mode interface onto my own remote transport node (on 1.2.5 now) and connected to it. That shut off the announces. Otherwise I'm still getting quite a few every second if I connect to the gateway interface instead.

But those are nevertheless confounding variables, so I'll take all of this back and run some more tests.

And thanks for caring about the Pixel 7a users in your latest Sideband release <3