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.

Comments

and speed was never the point of dropbox

[discovercomics]

In my mind speed and saturation of bandwidth is NOT what I want on a folder syncing service. Sync it up in the background for me.

Re:and speed was never the point of dropbox

[TFlan91]

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

Is it open source yet?

[Drinking Bleach]

There's no real point in using it if you can't even trust it does what they say it does...

Re:Is it open source yet?

[operator_error]

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.

Re:Is it open source yet?

[Junta]

It's not that difficult. But after setting it up for a group of people and then setting up seafile, I prefer seafile. If you aren't an admin user in owncloud, things are pretty tough when it comes to knowing what groups you are in and what groups can be shared with and such. seafile does a much better job on that front.

Plus the owncloud sync client doesn't seem very good. And the mobile platform clients cost money where seafile is free.

ownCloud might have gotten the 'good name', but they don't have the best implementation sadly.

Trickle

[Luthair]

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.

Re:Trickle

[Bengie]

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.

Re:Trickle

[Bengie]

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.

Open Source alternative to Bittorrent Sync

[gQuigs]

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

Re:Fancy version of FTP

[Anonymous Coward]

It was called X-windows in the 1980s,

That's X Window System to you, bub. That lawn you're on? It's mine. Off.

Am I missing the point?

[Arterion]

They copied some data across a local network. Then they compared it how long it took to transfer the same data to remote servers across their internet connection? 1.36 GB in 41 seconds is 33 MB/s, which is either extremely underwhelming for local network performance (I suspect a magnetic hard drive bottleneck), or extremely impressive for a fat internet pipe, neither having to do with the software in question.

Re:Comparing LAN to WAN Speeds

[MatthiasF]

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...

Encrypted node

[chrisvdb]

I've been using BitTorrent Sync for a year or so now. The main feature that was missing for me was the ability to set up an untrusted node which does not get access to the unencrypted data but can serve as a fast 24/7 proxy and backup system.

This functionality has now been added, although it's still in beta and only officially available in the API, not in the client... but a very simple hack makes it available in the client. This opens BitTorrent Sync open to 3rd party sync providers or cheap VPS.

The interface is still a bit quirky and designed for techies, but has also improved over time. Overall very happy with BitTorrent Sync.