New Members
  • Content Count

  • Joined

  • Last visited

About sty

  • Rank
    New User
  1. Currently, btsync only transfers two files at the same time from the same folder if the files are <12MB in size. Also, btsync seems to only transfer a single chunk at the time which feels like a very conservative setting. I'd like to propose that these were configurable, e.g. there would be a settings page where you can configure how many chunks can be on the fly at the same time and/or how many files/threads btsync can transfer/utilise at the same time. This would alleviate many low-transfer-speed problems with high-latency links because it partially sidesteps the transfer window size problem. Also some of the ISP throttling could be avoided this way.
  2. I have a similar issue, speeds being very inconsistent since I started using btsync in September (I think). Running currently 1.2.82. Both ends are linux servers and have very big files (30G+ each) on the sync folder. There's about 9000km of physical distance between the boxes but they have both static public IP's and no rate limiting/qos on. I did some testing and found out that if I have a folder inside the sync folder that has multiple files of different sizes between 3-15MB each, whenever btsync syncs sub-10MB files it send 2 files concurrently, resulting in more constant speed. Whenever it was time to sync a 10MB+ file it only did this on a single thread, causing the bandwidth to throttle after every 10 seconds or so and then pick up again until it throttled it again. On a network utilisation graphs this looks like a 'saw' pattern that was on the first post(s). When the sync moved on to a folder where I have these 30G+ files, it will never transfer more than a single file at the time which is very frustrating and underutilises the bandwidth available a lot. If I restart the btsync process on the sending side, it picks up (for sending) one of the files not synced yet randomly and continues normally. It would be nice to have a setting where we can set how many concurrent connections, threads or blocks to try to handle at the same time, going into tens of blocks per file and multiple files at the same time should be configurable.