Android battery use comparison: BitTorrent Sync, Dropbox, DS Cloud

[JimmyTheSaint]

1.1.27 Summary

BitTorrent Sync's constant wakelocks prevent the Android Deep Sleep necessary for tolerable battery usage.

Method

For these tests, I use:

• phone: Samsung Galaxy S 4
  
• battery statistics app: BetterBatteryStats
  
• cloud apps: BitTorrent Sync 1.1.27, Dropbox, DS Cloud (with Synology NAS's CloudStation cloud server)
  
• data sets (1.1.27-1.1.28): "SmallData" (100MB, 60 files), "LargeData" (23GB, 150k files)
  
• data sets (1.1.33-now): "SmallData" (60MB/60 files), "LargeData" (14GB/18,000 files)
  

Each trial begins with the battery at 100% unless otherwise noted. For the duration of the test, the phone just idles with screen off and no changes to data. Each result shows

• percentage of battery usage per hour
  
• l2_hsic kernel wakelocks (because it's the main culprit for preventing Android Deep Sleep, though other wakelocks are well-represented)
  
• percentage of time in Deep Sleep
  

1.1.27 Trials

1) BitTorrent Sync not running, Dropbox with LargeData, DS Cloud with SmallData

• LAN: 0.5%/hour, l2_hsic kernel wakelocks = 1.4%, Deep Sleep = 94.4%
  
• 3G: 0.7%/hour, l2_hsic kernel wakelocks = 3.5%, Deep Sleep = 82.4%
  

After #1, I didn't bother with separate 3G trials because it didn't appear that it would make a dramatic difference for comparision purposes.

2) BitTorrent Sync running with SmallData and automatic sync

• 10.9%/hour, l2_hsic kernel wakelocks = 63.5%, Deep Sleep = 19.6%
  

3) BitTorrent Sync running with SmallData and automatic sync + LargeData and no automatic sync

• essentially the same as with SmallData only in #2 above
  

4) BitTorrent Sync paused with SmallData and automatic sync

• 11.9%/hour, l2_hsic kernel wakelocks = 40.2%, Deep Sleep = 47.8%
  

5) BitTorrent Sync paused with SmallData and no automatic sync

• 11.3%/hour, ls_hsic kernel wakelocks = 74.5%, Deep Sleep 2.6%
  

6) BitTorrent Sync with no sync folders

• 2.7%/hour, l2_hsic kernel wakelocks = 8.3%, Deep Sleep = 65.6%
  

Discussion

BitTorrent Sync's Android app uses 20 times the power of Dropbox and DS Cloud combined because it prevents Android Deep Sleep. Pause, automatic sync, size of data set all have no beneficial effect on the ability to Deep Sleep. Even when all sync folders are removed (making the app useless), BitTorrent Sync's constant wakelocks still cause 5 times the battery use of the others. Dropbox and DS Cloud provide 24/7 sync with extended Deep Sleep, using little enough battery so that you can "set it and forget it." BitTorrent Sync, on the other hand, is awful--yet, it's manageably awful. >10%/hour battery drain still allows a full work day, but if data plan and video usage are thrown in, so is battery paranoia. On an S4, it's still not a disaster since the inexpensive batteries are easily swapped, but this kind of power consumption is easily a dealbreaker on phones with less baseline battery time and non-replaceable batteries.

Conclusion

Even though BitTorrent Sync's power consumption is manageable on my S4, it's demoralizing in comparison to Synology's CloudStation and Dropbox. Throw in BitTorrent Sync's general inability to properly move or delete any folder that contains non-empty subfolders and the Synology version's excessive CPU usage, and I just had to unlink everything and shut it down on all devices until (inevitably) these development issues are addressed. I left the software installed so that I can instantly update and test. It also sits there as an already quite functional backup system to be quickly brought online in case an issue arises with Dropbox or DS Cloud. I'm currently prepared to drop Dropbox entirely in favor of CloudStation; Dropbox is only acting as a backup for me anymore. But BitTorrent Sync would be preferable because it's decentralized.

[greentown]

Very good read. I haven't done such detailed tests, but your findings are in line with my experience using btsync for android: it used WAY too much battery, even when idling. I guess that being a beta, you can't ask for more. From what I've seen in other android apps, making a battery efficient application doesn't seem trivial at all. More so when the application has to periodically monitor a local folder for changes or to contact other systems in order to see if something has changed in the other side. I guess they still need to work a lot on it. In the meantime, I think that maybe they could give the android app some options to tweak those parameters and allow us to make the app a bit more battery friendly.

[GreatMarko]

Conclusion

Even though BitTorrent Sync's power consumption is manageable on my S4, it's demoralizing in comparison to Synology's CloudStation and Dropbox. Throw in BitTorrent Sync's general inability to properly move or delete any folder that contains non-empty subfolders and the Synology version's excessive CPU usage, and I just had to unlink everything and shut it down on all devices until (inevitably) these development issues are addressed.

...and I think that's the point - Sync has only been available on Android devices for a few weeks! It would have been interesting to see what DropBox, DS Cloud etc were like when they first came to Android devices - I suspect they may well have had "bugs" and battery consumption issues, etc too! My point is that, give the devs chance, and I've no doubt battery consumption will be drastically improved! It's a similar story to the very high CPU/Memory issues that some of the earlier builds of the desktop version had - the developers focus in the first instance on getting things working... and then once things are working, look at optimizing them! ...this has happened with the desktop builds... it will happen with the Android builds soon I'm sure!

That said, your post is excellent and very detailed! Thanks for sharing!

[JimmyTheSaint]

1.1.28 Summary

Great improvement in battery performance. The longest trial performed the same as Dropbox and DS Cloud. The other trials average 3.6%/hour, which is 5 times more, but probably only a problem for people who nurse their batteries.

1.1.28 Trials (See the first post for the method used.)

1) BitTorrent Sync running with SmallData and automatic sync for 60 minutes

• 2.6%/hour, l2_hsic kernel wakelocks = 10.7%, Deep Sleep = 60.6%
  

2) BitTorrent Sync running with SmallData and automatic sync for 62 minutes

• 3.8%/hour, l2_hsic kernel wakelocks = 16.6%, Deep Sleep = 44.4%
  

3) BitTorrent Sync running with SmallData and automatic sync for 235 minutes

• 4.4%/hour, l2_hsic kernel wakelocks = 14.7%, Deep Sleep = 46.4%
  

4) BitTorrent Sync running with SmallData and automatic sync for 470 minutes

• 0.7%/hour (83% down to 77%), l2_hsic kernel wakelocks = 10.3%, Deep Sleep = 62.2%
  

5) BitTorrent Sync running with SmallData and automatic sync + LargeData and no automatic sync for 245 minutes

• 4.7%/hour, l2_hsic kernel wakelocks = 13.2%, Deep Sleep = 32.5%
  

6) BitTorrent Sync running with SmallData and automatic sync + LargeData and automatic sync for 580 minutes

• 3.5%/hour, l2_hsic kernel wakelocks = 9.7%, Deep Sleep = 53.4%
  

7) BitTorrent Sync running with SmallData and automatic sync + LargeData and automatic sync for 240 minutes

• 4.2%/hour, l2_hsic kernel wakelocks = 12.9%, Deep Sleep = 46.2%
  

Discussion

During trial #6, my phone accidentally ran a backup that would skew the battery performance a bit, but the Android BitTorrent Sync app still took no performance hit for doing automated sync on a 23GB tree of 150k files. Trial #7 confirms the performance that's superior to Dropbox, which doesn't even allow automated folder sync (favoriting folders) lest your phone get permanently locked down in perpetually syncing. In the past, I have tried "favoriting" a large chunk of data with Dropsync, an app that bascially enables Drobox to auto-two-way-sync a large folder. It does indeed bog down your phone because any sync cyle of reasonable length makes your phone start checking through the entire tree structure again as soon as it finishes, pinning the CPU. I haven't tried automated sync on a large tree with Synology's DS Cloud/Cloud Station combo yet because there have been issues on the NAS side with large tree structures.

Conclusion

It appears BitTorrent Sync no longer imposes an onerous overhead just for having it run in the background while your data idles. Of course, if you start manipulating your data and force the phone to sync and upload and download, you're going to spend a lot more battery in a way that I haven't compared to Dropbox or Cloud Station. I would bet the battery cost of I/O would be high enough in any case so that any meaningful difference in these apps' performances would be obscured. But BitTorrent Sync still has room to improve its power usage, which is 5 times Dropbox's tiny footprint when syncinig a small data set.

[JimmyTheSaint]

1.1.33 Summary

With 1.1.33, I've started getting the pre-1.1.28 high battery consumption performance caused by a lack of Android Deep Sleep and excessive kernel wakelocks.

1.1.33 Trials (See the first post for methodology.)

1) BitTorrent Sync running with SmallData and automatic sync for 257 minutes

• 11.0%/hour, l2_hsic kernel wakelocks = 62.3%, Deep Sleep = 31.9%
  

2) BitTorrent Sync shut down for 68 minutes

• 0.9%/hour, l2_hsic kernel wakelocks = 3.6%, Deep Sleep = 93.9%
  

3) BitTorrent Sync running with SmallData and automatic sync + LargeData and automatic sync for 60 minutes

• 8.2%/hour, l2_hsic kernel wakelocks = 47.5%, Deep Sleep = 48.2%
  

4) BitTorrent Sync running with SmallData and automatic sync + LargeData and automatic sync for 243 minutes

• 9.9%/hour, l2_hsic kernel wakelocks = 51.6%, Deep Sleep = 43.0%
  

revert to 1.1.28 for sanity check

5) BitTorrent Sync running with SmallData and automatic sync for 243 minutes

• 6.2%/hour, l2_hsic kernel wakelocks = 31.8%, Deep Sleep = 64.3%
  

6) BitTorrent Sync running with SmallData and automatic sync plus LargeData and automatic sync for 248 minutes

• 11.9%/hour, l2_hsic kernel wakelocks = 73.7%, Deep Sleep = 21.3%
  

7) BitTorrent Sync running with SmallData and automatic sync plus LargeData and automatic sync for 422 minutes

• 10.7%/hour, l2_hsic kernel wakelocks = 56.2%, Deep Sleep = 37.5%
  

Discussion

When I updated to 1.1.33, I started seeing substantially increased battery usage, but I assumed it wasn't due to BitTorrent Sync due to the improvements seen with 1.1.28. When it persisted, I finally started collecting data in trial #1 above, and I made sure there wasn't some sort of anomalous CPU usage skewing the idling statistics by checking on battery usage once per hour. The running tally of battery usage was close to the final statistic, so it appears BitTorrent Sync has doubled its battery usage since 1.1.28. (In fact, I did these kind of spot checks with the earlier versions, too, to make sure that the final statistic was in line with the performance throughout the trial.) Although, trial #2 verifies the 0.9%/hour with BitTorrent Sync shut down, reverting to 1.1.28 now gives me higher battery consumption with LargeData. I ran many trials with 1.1.28 so that I could be confident in the results, but this latest data reduces confidence in my 1.1.28 trials.

Interestingly the Deep Sleep performance of 31.9%, while poor, is about the same as 1.1.28 trial #5. But the l2_hsic kernel wakelocks are way up, making it clear that Deep Sleep stats (like CPU stats) don't offer enough insight into the excessive battery usage. Happily, automatic sync with LargeData in 1.1.33 isn't any more costly than SmallData. >10%/hour is annoying, but if 10% buys you all-you-can-sync for an hour, that's something.

Conclusion

Regardless of my reversion to 1.1.28's inconsistencies with the earlier trials, BitTorrent Sync's battery consumption far exceeds Dropbox's and Cloud Station's. I had months of experience with those apps, so I'm confident that I understand their performance despite their small number of trials here.

[laurens]

Where did you get 1.1.33? I am CURRENTLY installing 1.1.28 from the play store?

Ow, and thanks a lot for your in-depth tests!

[JimmyTheSaint]

Where did you get 1.1.33? I am CURRENTLY installing 1.1.28 from the play store?

Ow, and thanks a lot for your in-depth tests!

Go to the "Latest Sync Build" thread and the page of downloads it links to has a link to the 1.1.33 apk.

My tests may be in depth, but they're really a piece of cake to do. All you need is BetterBatteryStats, which is always a nice app to have. The only "work" is leaving your phone alone for a long enough period to make the test worthwhile. It would be helpful if other people could do similar tests to raise confidence in the results.

[Yobobo]

I second your results with regard to 1.1.33. It does drain battery pretty bad.

Perhaps solving this problem fundamentaly is challenging. However, I think could be mitigated if the "Battery Saver" mode would work properly. Ideally, when the app is in "Battery Saver" mode, it should completely disconnect from peers, stop listening to ports, etc. Thus the app would stop preventing deep sleep. In reality, this mode stops syncing, but does not stop communications. I ran a quick tcpdump today and it shows continuous chatter between my phone and my PC, even when in Batter Saver mode.

Hope the developers have a look at this.

[JimmyTheSaint]

1.1.37 Summary

No change. Lack of Android Deep Sleep and excessive kernel wakelocks continue to impose a battery cost of 10% per hour.

1.1.37 Trial (See the first post for methodology.)

1) BitTorrent Sync running with SmallData and automatic sync plus LargeData and automatic sync for 243 minutes

• 10.9%/hour, l2_hsic kernel wakelocks = 58.3%, Deep Sleep = 36.5%
  

Unless someone suggests something to try, I don't see a reason to test 1.1.37's battery consumption further.

[Varnagas]

Thanks for doing this. Looking forward for further battery usage results on new builds. Keep up good work

[Yobobo]

What about battery usage in battery saver mode? I would like to know how good it really is (in light of my findings on not-so-saving network activity).

[Disappointed Cat]

There is no battery saver mode. All it does is stopping the app after dropping below the given percentage.

However there is WiFi throttling if the screen is off, managed by the OS itself.

So far, I found the best use-case is only running the app when you know you want something synced.

[JimmyTheSaint]

What about battery usage in battery saver mode? I would like to know how good it really is (in light of my findings on not-so-saving network activity).

I assume you're talking about Android's (or Samsung's) "Power saving mode," which automates things you can otherwise do manually. In fact, the way I use my phone is likely as much a battery saver as battery saver mode because of lots of settings I already do manually, and especially because I tolerate much lower screen brightness than people I know.

In each of my trials, the phone just idles, i.e., there are no screen ons, GPS, wifi, app updates, or intensive CPU processes. That provides a baseline reading that I can reproduce consistently. But all that really matters here is how much cost the BitTorrent Sync app imposes beyond your normal use, and it appears from my measurements that it's an additional 10% per hour. So one infers that if I used my phone intensively, say at 10% per hour doing other stuff, then adding BitTorrent Sync would result in 20% per hour usage. In fact, that's what I've observed when tethering my laptop to my phone's data plan: that normally costs around 10% per hour, and with BitTorrent Sync active, my usage goes up to around 20% per hour. BitTorrent Sync on its own is quite usable even with the excessive battery consumption (at least on my S4), but since I need to tether a lot, 20% per hour starts to move into impractical territory.

[Yobobo]

@Lightning @JimmyTheSaint I _am_ talking about BTSync's battery saving mode. Open BTSync settings - it's the fifth setting from the top ("Battery Saver"). You can set it to stop syncing if battery is below a certain costumizable level. If you set this, and the battery is low, the app shows a grey bar saying "Low battery level" on the bottom. This is only activated when the phone is not connected to a charger (which is great).

As I wrote in my earlier post (which was probably misunderstood), if this mode would have worked properly, it would be perfect to set it to not sync if battery is below %90. Problem is, it is not working properly. The app does not sync any file when the battery is low, but it does not disconnect communication with already connected peers. The result is constant network chatter that constantly wakes the phone from deep sleep.

[JimmyTheSaint]

What about battery usage in battery saver mode? I would like to know how good it really is (in light of my findings on not-so-saving network activity).

If the BitTorrent Sync app's "Battery saver" feature works as advertised, there's no reason to believe it will affect the rate of battery consumption before you reach its threshold. The feature is merely a safety net. I'm most concerned with how the app consumes power under normal conditions because I don't want to be reaching that threshold too often.

[JimmyTheSaint]

1.1.38 Summary

No change. Lack of Android Deep Sleep and excessive kernel wakelocks continue to impose a battery cost of 10% per hour.

1.1.38 Trial (See the first post for methodology.)

1) BitTorrent Sync running with SmallData and automatic sync plus LargeData and automatic sync for 274 minutes

• 10.3%/hour, l2_hsic kernel wakelocks = 57.4%, Deep Sleep = 36.7%
  

Unless someone suggests something to try, I don't see a reason to test 1.1.38's battery consumption further.

[v6ak]

I don't think that filesystem watching is the issue. Filesystem can be watched by inotify and it does not require any wakelock.

There is a different issue, though. The sync app uses network connections. Unlike Dropbox, it is probably not connected to a single server, but looks for other peers, which may require a wakelock. There are some possible ways around this issue:

a) A simple but not very powerful approach: Use a slightly centralized solution that notifies (by GCM) the phone about other peers. Note that there is probably no other way on iPhone, so something similar will be probably implemented. Disadvantages: SPoF + need to have an internet connection.

b ) Optimize peer connection to be push-like, if not optimized.

c) I am not sure if UPnP is battery friendly, i.e. if it can run completely without a wakelock. If not, I suggest a more battery friendly mode on background that possibly turns UnPNP totaly out.

Note: If neither b ) nor c) was an issue, there should be no reason for wakelock.

[JimmyTheSaint]

1.1.48 Summary

Auto sleep functionality has restored normal battery consumption when idling. Battery consumption increases substantially if there's file activity on other clients.

1.1.48 Trials (See the first post for methodology.)
1 (considered anomalous) BitTorrent Sync running with SmallData and automatic sync plus LargeData and automatic sync for 57 minutes, with auto sleep set to check every 15 minutes

• 11.3%/hour, l2_hsic kernel wakelocks = 88.2%, Deep Sleep = 6.6%

2) BitTorrent Sync running with SmallData and automatic sync plus LargeData and automatic sync for 247 minutes, with auto sleep set to check every 15 minutes

• 2.7%/hour, l2_hsic kernel wakelocks = 4.1%, Deep Sleep = 72.4%

 

3) BitTorrent Sync running with SmallData and automatic sync plus LargeData and automatic sync for 120 minutes, with auto sleep set to check every 15 minutes

• 5.6%/hour, l2_hsic kernel wakelocks = 5.6%, Deep Sleep = 59.0%

Discussion

I set the auto sleep check to every 15 minutes instead of 30 because a 15 minute period is already minimal. For example, Dropsync doesn't unduly drain the battery when set to 5 minute intervals used in conjunction with Dropbox to provide functionality similar to BitTorrent Sync. Trial #1 looks like an anomaly of some kind. I can't find an explanation, but perhaps Android's media manager or the anti-virus app Lookout acted up during the trial. But I don't know if those apps could cause the l2_hsic wakelocks. Before trial #1, I did a 4-hour trial, but discovered at the end that my 3G connection to the internet had been lost, which is a rare error, but I don't know if BitTorrent Sync was involved. That trial only cost 0.5% of battery time per hour, so BitTorrent Sync doesn't continue to drain power when it's running but disconnected from the internet. Trial #2 gives the kind of battery performance expected from my S4 when it's idling. The point of this thread is to check the app's "baseline" consumption rather than make fine determinations about battery consumption under different loads and file activities. I checked in several times during the four hours, and the final %/hr stat is in line with what I observed at different points during the trial. Deep Sleep did vary from 59.1% to 87.1%, who knows why. Trial #3 also makes #1 appear anomalous, so that I think this will be my last trial, and I'll consider the battery consumption problem solved until there's a reason to think otherwise.

 

I should add that obviously file activity on other clients will increase battery consumption. I've only measured idling battery consumption because it's easier to control. But when my phone was idling, file activity on another client did see my phone go past 10%/hr once again. I assume it's due to BitTorrent Sync, but the size of the data needing to be synced wasn't very big. It did change often, though (about once per minute or more), but I would think that BitTorrent Sync would still only wake up to check every 15 minutes, so the jump in battery usage seems out of line with the way the data was changing. Perhaps there's something there the devs can adjust for. In any case, this will be my last test unless something unseemly happens.

 

 

 

[greentown]

Jimmy, your analyses are very interesting. I had high hopes for the battery issues with 1.1.48, however your findings are disappointing. I'd be very interested to know of any updates with, hopefully, better news.

[JimmyTheSaint]

Yeah, I think it's strange because totally sleeping the app and waking it up every 15m seems like a simple and straightforward solution to excess battery drain. In addition, I had nearly zero file activity on any client during the test period, maybe one small text file changed 1-2 times. And the app was never in the foreground during the test, so there's no chance I accidentally woke it up. I can't do a long and careful test for a day or two, but a couple of casual tests since the one above have shown 4.8-6.6%/hr battery consumption, which is in the ballpark of normal battery consumption for the way the phone was being used during those times. Also, I do see my Android phones disappear from other clients' devices lists, so that expected behavior is verified.

[JimmyTheSaint]

update: 1.1.48, trial #2 above.

[JimmyTheSaint]

After trial #3 above, I've concluded that auto sleep has improved battery consumption in the expected and desirable way. Unless something goes haywire, I'm optimistic that this thread is done.

[itsjustmatt]

What I've found is that it's not the BT Sync on the phone that's draining the battery, it's the constant pinging upon the phone whenever the desktop client is running, *even if BT sync isn't even running on the phone*. As soon as I stop the desktop client, battery drain goes back to normal.

 

SG3, 4.3 Eclispe ROM

[Disappointed Cat]

That's why the droid client disconnects from other peers when it goes to sleep mode.

[capi]

I also see a lot of wake-ups on the phone since I have btsync running inside my network. It could be that Android is woken up a lot by the multicasts that is used by LAN discovery (even if btsync is NOT running on the phone). Will try to disable LAN discovery and use hard-coded IP adresses and have a look if this improves the issue.