Syncthing-Fork v2 uses far too much battery over v1

Support Android
112

Well, I did not try it but I suppose that could work. I do need it to sync when on mobile data, though.

113

What I’m getting at is that if it is a generic “cellular uses a lot of battery” issue, local discovery is one of the few things that could use cellular data when Wi-Fi is available, as useless as local discovery on cellular is.

I would need debug logs for beacon to know whether local discovery is actually broadcasting/multicasting on the cellular interface (as that only happens when mutlicast/broadcast flag is set). Although, I don’t think the current debug logging on the broadcast side is verbose enough to know the interfaces associated with the broadcast addresses ATM:

1 Like
115

Actually I compared three different setups:

  1. syncthing 1.30.x: ~2-5% share of consumed battery power
  2. syncthing 2.x stock config: ~50-70% share of consumed battery power
  3. syncthing 2.x with reduced beacon interval: ~10-12% share of consumed battery power

Just being precise here. :wink:

2 Likes
117

I have returned to 1.30.0.4 app version due to less battery consumption.

I can’t update app to version 1.30.0.5 on Pixel 9a. The app tries to update, but nothing happens. Only info: App not installed. I disabled advanced protection to install it.

Why version v1.30.0.5 is not available on F-Droid?

118

This is strange I can’t update from 1.30.0.4 to 1.30.0.5 on Pixel 9a.

But I can install 1.30.0.5 on Pixel 7a.

But upgrade from 1.30.0.4 to 1.30.0.5 on Pixel 7a is also impossible. There is an info about conflict with existing package (1.30.0.4).

119

I can install Syncthing-Fork v1.30.0.5 directly on Pixel 7a but I cannot install it on Pixel 9a.

Why?

120

I used the Ethwork app to gather more information on my Pixel 10. A few interesting observations:

  • dummy0
    • Up
    • Multicast: false
    • P2P: true
    • has only IPv6 link-local addresses
  • lo → loobpack
  • wlan0 → the wifi interface
  • rmnet16
    • Up
    • Multicast: true
    • P2P: true
    • global unicast IPv6 (mobile)
  • v4-rmnet16
    • Up
    • Multicast: true
    • P2P: true
    • private IPv4 (mobile; CGNAT?)
  • rmnet17
    • Up
    • Multicast: true
    • P2P: true
    • global unicast IPv6 (mobile)

Note that all of my cellular interfaces don’t support multicast. I can’t tell with this app if they support broadcasts though. If they don’t, we shouldn’t even wake them up for discovery with the patch provided by @marbens

2 Likes
121

You mean not all of them? There is a difference between all of them not supporting multicast, and not all of them supporting multicast.

I can see a few interfaces that have “(mobile)” and “Multicast: true”.

1 Like
122

If it’s an app which just uses the official APIs, then afaik Android’s NetworkInterface doesn’t support the call to determine whether they support broadcast or not: https://developer.android.com/reference/java/net/NetworkInterface

Apps like Tailscale, which worked around this issue, seem to treat Multicast support equal to Broadcast support.

But honestly, one can wonder whether Local Discovery is such a bright idea for (very) mobile devices - just saying.

123

My bad. Updated the post accordingly. All of them support multicast.

I wonder if we could simply provide a glob based blacklist/whitelist for interfaces? That would also be useful for non-Android platforms.

Edit: do we even need local discovery on P2P interfaces?

1 Like
124

I managed to pinpoint the cause of the battery drain. Simply disabling my mobile data overnight was enough to get Syncthing v2 back to <1%. We already knew that disabling local discovery or at least increasing the time between runs brought battery usage back to v1 levels.

So the problem seems to be the frequent wakeups of the mobile radio. Wifi is apparently not affected as there was no drain while my phone was only running on wifi.

My proposal: we should block local discovery on P2P interfaces, at least for the Android platform.

8 Likes
125

Did you just disable mobile data via the toggle in the Quick Settings tile, or did you activate airplane mode?

I generally deactivate mobile data when I am at home (or have a stable WiFi connection), but nevertheless I have experienced the battery drain issue.

126

I fully disabled my SIM card.

2 Likes
127

I’m a bit busy with the family for the next few days, so testing on my end will have to wait. But feel free to give it a spin @nel0x @researchxxl

8 Likes
128

I applied the patch to the latest version of the app, and the battery usage dropped to <1%. Thank you for fixing the issue!

3 Likes
129

I don’t know what changed, but my battery usage is below 1 percent. I’m using the latest F-Droid app.

I returned to my default options with minor changes. Syncthing-Fork from F-Droid version 2.0.12.1 on Pixel 9a.

Desktop app settings v2.0.12 Linux on openSUSE Tumbleweed: Connections - All enabled Limit Bandwidth in LAN Enable NAT traversal Local Discovery Global Discovery Enable Relaying

Advanced: Num Connections to 0 (default)

Remote device: Edit/Advanced Addresses: dynamic

I sync 5 folders. Four of them are for receiving only, and one is for sending and receiving.

Android Synchting-Fork v2.0.12.1 settings: Run Conditions - Run on Wi-Fi, Duration of sync - 5 minutes, Duration of pause - 60 minutes, Run on specific Wi-Fi - Disabled Syncthing options: All enabled except Global

Android Settings - Battery - Battery usage: Allow background usage is enabled and optimised. App shows <1%

Active apps Syncthing-Fork is active 23 hrs.

I will monitor my battery consumption. But for now my Pixel 9a is Up to Date (Remote Devices) on desktop app and Syncthing-Fork battery stats do not increase.

130

@pixelspark i wonder if this kind of battery drain is also a thing - to a lesser extent - on iOS? The tl;dr version of the whole thread is that our current local discovery code is waking up the cellular interface even while the phone is connected via wifi.

131

“Running in the background” is less of a thing on iOS.

2 Likes
132

Correct, see e.g. here for some more details. Long story short, the app will not run for very long (>1m) in the background unless (1) it’s on the charger and iOS is in a good mood, or (2) the user requests it to (iOS 26 onwards). I have not measured whether (nor noticed that) the power usage is larger while running due to local discovery.

Edit: on macOS the app does run in the background, there I can imagine it (as well as other things that wake up the app frequently) makes a difference to battery life.

133

I guess that will be the same on all desktop-like systems, right? There are quite a few laptop/tablet devices running desktop OSes with SIM cards too.