JimmyTheSaint

2 years in some places

In some areas, Dropbox was also giving 50GB for buying a Samsung phone.

I don't know because I only experimented with increasing the number of files and the total amount of data in a corresponding way. Why don't you do some file count vs. file size tests and report the results?

143,281 files and 16GB isn't "just." Compare with my stats above, and you'll see that your experience jibes with mine. I don't think there's anything to do but wait for the app to develop. Currently, I only use my Linux NAS to sync a 60MB/60-file tree, which requires 0.2% CPU.

Try reducing the amount of data and see if you get corresponding reductions in CPU and memory usage. Perhaps post the size and file count of your sync folders here.

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.

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.

One of my Androids (Note 2) maintains automatic (LAN) sync on a small (60MB, 60 files) folder, but never completes automatic sync with either of two other 10GB folders. My other one (S4), which has an overall similar setup, automatic syncs fine (3G), as do my Windows devices. I don't see any errors, and there is still plenty of room left on the SD Card, but the app just eventually idles with no up/down activity. I've tried restarting the app and rebooting the phone. From a Windows client's "Devices" tab, I can see that the device is stuck with 2.1GB still to upload on one folder and 400MB on the other. In the "History" tab, it reports "Finished syncing with Note 2." On the device itself, I've located some files that it sees in "All Files," but hasn't downloaded. I can download those files manually, no problem. I can't find a pattern to the stuff that remains to be synced, so I couldn't simply complete syncing manually. Any ideas? EDIT: As far as I can tell, all of the undownloaded files come from one subtree that mostly contains pdf files. Possibly there are other files in other places, too, but that one 7.75GB subtree is 2.05GB short of full sync, so apparently accounts for all of the 2.1GB shortfall. EDIT: I deleted everything from the phone and started syncing from scratch. The phone stops downloading with 59.3MB remaining out of 4.55GB. That's 3583/3584 folders and 12163/14374 files according to the file mangers' stats, though I haven't been able to determine yet which subfolder has failed to automatic sync. I try pause and resume on that folder, restarting the app, and rebooting the phone, but it just won't continue dowloading at all. Apparently sync and everything still works, it's just that the automatic sync never fully downloads.

Vole (http://vole.cc/) is worth listing here. I'm hoping for more development, especially an Android app.

1.1.69 continues the same or slightly worse on my Synology NAS: 10GB, 37,000-file directory takes up 5-8% CPU where no other process is above 0.2%. My 90MB, 60-file directory was 0.2%, but adding more stuff still requires unacceptably high CPU usage. Big disappointment given the improvements in the Android app. The Windows version continues to stay low at <1%.

I just tested it, and autostart works.

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.

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.

You're exactly right: I want to leave it on continuously 24/7 so that my phones stay in sync with my stuff. That way, I can always grab one and go and be confident that all my stuff is already at my fingertips and that I'm not about to create a bunch of conflicts. The point is to not have to hover over my sync app and constantly nurse it. It just works, and also serves as yet another backup of my data. Several backups are desirable because I don't have some large corporation serving as my rock-stable repository of last resort, such as Dropbox. Dropbox works great, but I want to replace it for financial and privacy reasons. Dropbox runs continuously without devouring the battery.

My Synology 213+ is PPC (QorIQ P1022) and runs BTSync fine. I believe my glibc is 2.8. So the OP's problem must be the different PPC architecture (PowerQUICC III MPC8533E)?

Did you move or delete folders that have subfolders without the outer folder reappearing?

Is there one that plans to support Windows, Synology NAS, and Android?

You're doing a lot better than me: http://forum.bittorrent.com/topic/21884-is-20-45-linux-nas-cpu-usage-too-high/

With 1.1.27 on both my deviced, sync stops completing once I've deleted and re-added some folders when working in my large folder. I haven't tested to see precisely how much file manager manipulation is required before sync stops. The app continues to reflect the correct state of things since the unsynced files don't appear on the "DEVICE" side (their enclosing folders appear, but are empty), and the files show as not yet synced on the "REMOTE" side. So the error is basically that sync becomes manual-only in folders I've been working on.

If an IP inadvertently gets banned, how do we get it un-banned?

Removed.

Here's a suggestion you can investigate because I haven't looked into it myself: perhaps you can use a permissions restricting app like XPrivacy to prevent BTSync from leaving the LAN without disabling it on the LAN. XPrivacy is a great app and has lots of permissions in its internet category of restrictions, so perhaps there's some combination to do what you want. I'd be curious to know if you get it to work. XPrivacy technical discussion at XDA is at: http://forum.xda-dev...d.php?t=2320783

Direct downloads of BTSync are here: http://syncapp.bittorrent.com/1.1.42/. The APK is recent, but not current. Assuming I didn't make a mistake when extracting with Titanium, here's the 1.2.27 apk: <link disabled at dev's request>

1.1.48 continues the same: 10GB, 37,000-file directory takes up 4-7% CPU where no other process is above 0.2%, with one exception. My bittorrent client, Transmission 2.77, is at 2-5% CPU sharing 8 torrents (estimate 1000 files) that will eventually total 52GB. At the time of my previous post, Transmission wasn't running as many torrents. Every 10 minutes when syncing, the btsync process runs at 40% CPU. Any opinions if this btsync CPU performance on my Synology is within the realm of reasonable? I guess 4% CPU is OK given that my bittorrent client performs about the same. But if progressively adding my full complement of data to sync is going to progressively push btsync's CPU to a constant 40%, I'd be curious to know if that's to be expected and tolerable. I also tried turning on and off Synology's indexing service on the synced directory, but that made no difference to the btsync process's CPU usage.

Starting with 1.1.27, the Android app shows a standard settings icon at the right side of the folder name. It should now be easy to touch the correct area.