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.

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.

They apologized a few weeks ago at https://twitter.com/volecc that the devs have been busy. I would think that means they intend to come back to Vole eventually.

Syncing to the external SD card works fine on my S4 and Note 2.

try forum search: http://forum.bittorrent.com/topic/22376-android-battery-use-comparison-bittorrent-sync-dropbox-ds-cloud/

How long does it pin the CPU? On my Linux NAS, the initial sync of a directory pushes the CPU very high until it finishes indexing, and then it drops to a CPU usage that depends on the size of the directory. Then it spikes briefly every 10 minutes. Does your CPU settle down after the first indexing?

In general, try using the forum search function first, which turns up this thread: http://forum.bittorrent.com/topic/21754-bittorent-sync-and-nas-ds213 In that thread, there's a link to this document for manual installation: http://goo.gl/0o1Gh

Apparently, sync problems arise if you re-name the same file too many times, before it's done syncing each name change. One problem I've seen on my Android devices is that the file shows as still syncing under its old name under the "All Files" tab, not under the "On Device" tab. Of course, it never completes syncing and can't be manually downloaded because the file doesn't exist--it just continues to be listed with the download progress bar stuck at zero progress. What's the best way to clear this situation? When the problem arises, it's only on my Androids and none of my other devices displays a problem as far as I can tell. The Androids show as fully synced in the BTS control panel on the other devices. Once, the only way I could find to clear it was to unlink and delete that folder on all devices and sync again, which was fine because it was a small folder, but that's rarely a practical solution. Another time, I discovered a corresponding orphan.!sync file on one of my Windows boxes. Deleting the .!sync file didn't enable my Androids to clear the bad entry. Recreating the ghost file on Windows did allow Android to sync it, and then I was able to delete it on Windows and the deletion synced properly on all devices. But is there some way to directly clear a ghost file under the "All Files" tab from within Android? I look though BTS's hidden files, but I don't get a clue.

When my phones leave my LAN, they sync over 3G, no problem. Something must be going wrong in your case.

Have a look at http://forum.bittorrent.com/topic/18614-syncing-not-completing/

While we're into repeat posts, I'll add: after syncing about 2.5TB, I've observed a rather consistent 2.5-3.0MB/s on both of my Synology DS-213+'s with the CPU at 50-60%. They're currently on the same gigabit LAN. A tree of mostly large media files synced at a consistent 4.0MB/s, which is a big difference as it reduced that estimated initial sync time from about 90 hours to 60 hours. I didn't notice the speeds when I synced my other devices because those folders were a max of 10GB. So I can't really judge if this all-Synology performance is "slow." Copying files directly over the LAN runs at 40-60MB/s.

The .SyncArchive folder that stores deleted stuff depending on your settings?

After syncing about 2.5TB, I've observed a rather consistent 2.5-3.0MB/s on both of my Synology DS-213+'s with the CPU at 50-60%. A tree of mostly large media files synced at a consistent 4.0MB/s, which is a big difference as it reduced the estimated initial sync time from about 90 hours to 60 hours.

Any per hour battery usage estimates for the BitTorrent Sync app on these other devices? On my S4, it costs an extra 10% of battery capacity per hour.

In BitTorrent Sync's Devices tab on one of my Windows laptops, there's a cloud-like icon next to all the folders shared with my S4. All other devices have two opposite-pointing arrows, including my other Android device, my Note 2. The other Windows laptop I checked has only the arrows icon, and no cloud. wtf? I've attached a pic.

My sync.conf contains the following comment right above where it says "shared_folders": /* !!! if you set shared folders in config file WebUI will be DISABLED !!! shared directories specified in config file override the folders previously added from WebUI. */

Battery usage?

Only my Android clients fail to sync completely. One comes up 17MB short and the other is 61K short, both on the same folder. No clue how to trace them down as I eliminated characters that can cause trouble from filenames a long time ago, and also don't have overly long filenames.

I added my 760GB/70,000 files folder to sync with 1.1.70 (currently with no sync peers), and that's imposed an additional cost of 7% CPU usage by pushing it to a consistent 11-13%. This also reflects a great improvement from 40%, but is it a reasonable cost for such a process to impose on the CPU when operating with this much data? I don't know. Of course it would be great to see CPU usage optimized further, but I also don't know how unhealthy it is to run my CPU at a constant 19% as opposed to its baseline server usage of 4%--I mean, obviously it's more wear and tear, but is it reasonable from a costs/benefits point of view? Or am I inviting an unnacceptably high rate of motherboard replacement? I tried asking at the Synology forums, but have never received a response. I will only be able to sync the very large stuff with one other client due to space limitations. So one plan would be to shut off sync most of the time and restart it on the two devices manually, periodically. But that kind of sucks because the idea of these two NAS's is to keep them at different locations, with the remote one capable of being brought online as the main one in the event of a hardware failure. In that emergency case, if the second server isn't 100% up to date with the large data directories, it's not a disaster, but would still be a pain.

With 1.1.70, I'm now getting a consistent 4-6% CPU usage with sync folders of 60MB/60 files, 10GB/5000 files, and 4.5GB/14,000 files. That's looking pretty good, and I'm comfortable using it now. Periodic 10-minute spikes of 40%. When I first added the 10GB/5000 files folder, I quickly eyeballed the CPU load as lower, maybe 3%, so I infer that adding more stuff increases CPU significantly even if the relation is less than linear. So I'm hesitant to go for the big test with my folders of 760GB/70,000 files and 300GB/88,000 files, particularly because I currently don't have another client set up that can sync that much along with my Synology NAS. But I'd really like to have that kind of sync capacity if it won't fry my CPUs.

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.

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.

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.

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.

As I posted here; http://forum.bittorr...till-uploading/ sync sometimes just fails to complete for some still unaccountable reason. All my devices have the same .SyncIgnore, so I can rule that out, and the permissions issue doesn't seem likely because other devices are able to complete sync. The trouble with debugging this problem is that finding the non-syncing files is like looking for a needle in a haystack. By luck, I found one folder that woudln't sync for no apparent reason, so I re-copied its content between two of my other devices. That enabled the incompletely syncing device to suddenly sync much more of that stuff. But there it remains with some mysterious 17.1MB that it just never finishes, despite different device reboots, etc. over the last few days. I have no idea which files they are, so that sucks. The recalcitrant files that I did discover individually synced manually no problem, so in fact it appears to complete indexing, though I'm unable to verify that. But it's a mystery as to why there's this failure to complete automatic sync.