Slashdot Mirror


BitTorrent Performance Test: Sync Is Faster Than Google Drive, OneDrive, Dropbox

An anonymous reader writes Now that its file synchronization tool has received a few updates, BitTorrent is going on the offensive against cloud-based storage services by showing off just how fast BitTorrent Sync can be. More specifically, the company conducted a test that shows Sync destroys Google Drive, Microsoft's OneDrive, and Dropbox. The company transferred a 1.36 GB MP4 video clip between two Apple MacBook Pros using two Apple Thunderbolt to Gigabit Ethernet Adapters, the Time.gov site as a real-time clock, and the Internet connection at its headquarters (1 Gbps up/down). The timer started when the file transfer was initiated and then stopped once the file was fully synced and downloaded onto the receiving machine. Sync performed 8x faster than Google Drive, 11x faster than OneDrive, and 16x faster than Dropbox.

7 of 124 comments (clear)

  1. Re:and speed was never the point of dropbox by TFlan91 · · Score: 3, Informative

    That's completely independent of speed, what you are talking about are limits and/or throttling, both of which are sliders in settings.

  2. Re:Is it open source yet? by operator_error · · Score: 4, Informative

    Here's an 'unofficial' open-source bit-sync client:
    www.yeasoft.com/site/projects:btsync-deb:btsync-server

    It doesn't install on .rpm based distros so far as I can tell. I have a use-case that calls for drop-dead-easy cross-platform sync, and I'm leaning towards using git-annex assistant, but haven't had time to thoroughly test it yet.

  3. Trickle by Luthair · · Score: 3, Informative

    These programs are designed not to saturate the upload/download pipes ruining the connection for all the users. So congrats, your protocol has all the problems of BitTorrent.

    Ruining the connections since 2001.

    1. Re:Trickle by Bengie · · Score: 5, Informative

      They are not designed to not use all of your bandwidth, it's that they can't. I've tested DropBox, and it breaks up the file into chunks and uploads them synchronously using REST calls. This meant my connection was constantly bouncing between 0% and 100%, causing bursts of packet-loss because it never gave TCP enough time to level out. BitTorrent on the other hand is great at not hosing my connection. I can run it near 100% and it will back-off as it detects latency going up, preempting the need for packet-loss to signal congestion.

    2. Re:Trickle by Bengie · · Score: 4, Informative

      I have a 50/50 dedicated fiber connection with a rock solid 0.35ms ping to my ISP and a solid 8ms ping to drop box servers. Why is my connection only doing 10mb/s with DropBox and getting packet-loss, while I can use BitTorrent at 45/45 up & down at the same time and not have loss or latency? DropBox seems to have the bandwidth, but the quick bursts are wrecking havoc with my ISP's traffic shaping via their Cisco router. The way Cisco is calculating the mb/s seems to be via some sliding window, which allows a quick spike of a burst to happen in the first 1/4 of a second, but then clamps down. Because my network latency is so low, the TCP stream can ramp up really fast. Once the Cisco router clamps down on the connection, I'm already uploading nearly 100mb/s and TCP can't back off in time before loss happens.

      The reason loss occurs after the clamping is because my ISP uses small buffers. They don't like buffer bloat. My max latency to my ISP before loss starts to occur is about 10ms. Since the connection is dedicated, and their trunk is sized about 3x more than peak bandwidth, it's normally not an issue.

      This wouldn't be an issue if DropBox transferred the data as a single stream, but instead does a very jarring start/stop cycle, which causes my bandwidth to get very spiky. I'm thinking of enabling traffic shaping on my PFSense box, but I really don't feel like messing with it quite yet.

      I guess the actual problem really is the Cisco router, but DropBox is still incredibly slow.

  4. Open Source alternative to Bittorrent Sync by gQuigs · · Score: 3, Informative

    is https://ind.ie/pulse/ (was SyncThing).

  5. Re:Comparing LAN to WAN Speeds by MatthiasF · · Score: 5, Informative

    Maybe because 3-4 people actually read the Sync blog post where it states, and I quote:

    "Our tests were conducted over local LAN – on the same switch – in order to rule out available bandwidth as a limiting factor. It’s important here to note that Dropbox, Google Drive and Microsoft OneDrive all rate-limit uploads and do not fully utilize the 1 Gbps bandwidth available (in regards to the office Internet connection, not the LAN switched). We’re confident that a slower Internet connection would yield similar results."

    In other words, people agreed with me because they knew what I said to be true.

    Not only did they give themselves the preferential treatment of same LAN, they also intentionally adjusted their tests to discount an advantage of a competitor. Again, quoted verbatum from the blog post:

    "Dropbox has a deduplication scheme in place – what this meant for our tests is that even though we deleted the video file from our Dropbox folder, traces of it still remained and Dropbox got ~50% faster at transferring the same video file each subsequent time we uploaded it. To correct for this, we needed a new file that wasn’t bit-for-bit identical to the video file we previously transferred. "

    Why don't you RTFA.

    http://blog.bittorrent.com/201...