no1453

Members
  • Content Count

    2
  • Joined

  • Last visited

About no1453

  • Rank
    New User
  1. I've run into problems with other transfer methods with lots of small files, so I usually bundle the data into a monolithic rar file. FTP behaves poorly (not reaching bandwidth available), Http does very well, but I haven't felt like installing a server on all my machines; simple drag and drop over the network is unreliable with large files. This particular transfer was from a Windows 8.1 machine to a Mac Mini with wired connection through my router, maybe the cross-platform difference caused some of the "slowness" (though 1.1 MB/s isn't completely slow). With default buffer sizes, it would transfer quickly for the first few minutes, but then slow down to 600KB/s-1.1MB/s, it seemed that the presence of other network traffic (Netflix, for example) would put BT Sync "off its game". I have had good speeds transferring over the Internet, but on my LAN the only thing that gave me top speeds was changing the buffer sizes. (And my impatience might be a factor, I've noticed lately it seems to take a while for BT Sync to ramp up to speed.)
  2. I've been trying to get BT Sync to transfer files quickly between machines on my LAN ever since it was first made available. But speeds have been quite erratic. Finally I found a setup that is performing well, and I just thought I'd share it. Not sure how vital these changes were: I enabled "Use predefined hosts" on both machines, set "lan_encrypt_data" to False. (Both machines) What seemed to be vital to getting speeds up: finding the right values for "recv_buf_size" and "send_buf_size". With the defaults (10/10), it kept settling at ~1 MB/s. So I tried 32/32, but the improvement was minimal. I then tried out 24/24, and the results were dramatic: I started getting 6-10 MB/s. The particular values might be specific to my setup, but with experimentation I'm sure others can find their own "butter zone" values. The main lesson I learned that applied to BT Sync buffer size was: bigger isn't always better.