Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Data Storage

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

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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by discovercomics ( 246851 ) on Wednesday October 22, 2014 @06:06PM (#48207853) Homepage
    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: (Score:3, Informative)

      by TFlan91 ( 2615727 )

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

      • ...

        And who knows, I didnt care to read tfa, but they couldve developed a nice algorithm like that new hit show I cant remember the name of

        • by ihtoit ( 3393327 )

          ...and like that new hit show, such an algorithm will ever remain the figment of someone's deranged imagination.

          (I mean, seriously?? A plane that size doing 200mph eight feet off the ground not a: smashing engine pods to bits and/or b: flipping due to ground effect? And why couldn't they just fucking land it, they had the time and apparently the runway...)

          • by Anonymous Coward

            "(I mean, seriously?? A plane that size doing 200mph eight feet off the ground not a: smashing engine pods to bits and/or b: flipping due to ground effect? And why couldn't they just fucking land it, they had the time and apparently the runway...)"

            And that other show, where there is that doctor that cannot die, who, when killed, appears under water, naked.

            But apparently the phone in his clothes, that disappear with him, are magically transferred to a new suit at home, where he can use it again when needed.

            I

            • by BLKMGK ( 34057 )

              Actually I'm pretty sure he never carries a cell phone. In the last episode one rings in his pocket, having been planted there, he's surprised, and he ultimately ditches it. One must wonder about his wallet though... Overall Forever hasn't been all that bad. Scorpion has also gotten a little less far-fetched but not much. It's still fun to suspend belief and just watch rather than trying to pick it apart.

            • And that other show, where there is that doctor that cannot die, who, when killed, appears under water, naked.

              Wait, what show is that?

              Or was it a dream you had?

        • by Anonymous Coward

          Silicon Valley? "Meet in the Middle" / "Pied Piper"?

        • And who knows, I didnt care to read tfa, but they couldve developed a nice algorithm like that new hit show I cant remember the name of

          Black Jesus?

      • by dbIII ( 701233 )
        Yes I know, but throttling users who set poor limits is generally frowned upon and tends to hurt your fingers after a while.
    • And all the others were uploading an online copy too, so this isn't a like-for-like comparison (I think that DropBox, at least, supports direct local network copying but would probably be making the online backup at the same time).

    • by StarFace ( 13336 ) *

      You should be relying upon bandwidth throttling features to do that for you, not the inefficiency of your tech. Speed is vital in this market because speed reduces the chances of causing data conflicts. Slow and steady background uploads increase risk of conflicts as the average user doesn't pay attention to upload/download status before shutting down a machine or resuming work. Faster transfer reduce problematic "lazy" sync usage at a statistical scale.

  • by Drinking Bleach ( 975757 ) on Wednesday October 22, 2014 @06:07PM (#48207863)

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

    • by operator_error ( 1363139 ) on Wednesday October 22, 2014 @06:13PM (#48207921)

      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 [branchable.com], but haven't had time to thoroughly test it yet.

      • That isn't an open source implementation of btsync. It is just an unofficial debian package that installs the official proprietary btsync binary. It makes it easier to install and update btsync on debian based systems, but it is the exact same software that you download from the official site.

    • by suutar ( 1860506 )

      No, but there is an open source bittorrent based syncer called "syncthing". It's not as mature, but it is supposedly functional. Have at :)

      • It's actually called Pulse [ind.ie] now and it's source can be found on Github [github.com] under the old name.
        • For my workgroup/use-case we looked into Syncthing/Pulse and ruled it out because another requirement of ours is read-only sharing/distribution. So far, we're still stuck using the official Bit-Torrent Sync. In other words, so far, given our long list of fairly strict requirements, Bit-Torrent Sync sucks less then everything else.

          I'm hoping git annex assistant will pass testing once I get to it. We're trying to distribute files using wifi at open-source conferences, using some kind of LAN technology, since

    • None of the services listed are open source, so that is a red herring. Open source isn't even particularly important here, because your data isn't locked into any kind of a format - you can switch freely to any service at any time, and you have a complete copy of your data at all times. If you really need open source, there are options which require a server: SparkleShare works well for me, and I understand that OwnCloud has something that works decently as well.

      My problem with the service is that it works

      • OwnCloud is open source and does the same things as Dropbox (although in really crappy PHP on the server, so you'd better have a lot of spare cycles to burn - it's the first time for several years I've seen file transfers across the Internet be CPU limited).

        The problem is that they're comparing apples to oranges. Of course a direct local connection will be faster than two devices sharing the same Internet connection and going via a server, but most of the time that I want to use a server as part of a sy

    • by BLKMGK ( 34057 )

      It doesn't even do anything for me. It was working and then just stopped. No files synch for me and both the handset and the computer it's supposed to synch with are 'net reachable. Nothing changed in the config of the PC so I have no idea what happened. I've tried dorking with settings and updating every time something new comes out - doesn't help...

      • That's odd. The newer versions on the phone have the option to force sync though.

        Just hit the menu button and it will give you an option for "Sync".

        It might start working again after that, also there is a possibility that the options for your folders has changed. They have the option of syncing automatically or just syncing the file description until you click on it.

        I hope this helps you.
    • by Kjella ( 173770 )

      Google Drive, OneDrive, Dropbox

      They all have your data, they can do whatever the f... they want with it. Unless you're talking about a client backdoor to access all the other files you didn't want to share with the cloud, but I don't think any of the others are any better. If you want real control, it's ownCloud or no cloud I think...

      • If you want real control, it's ownCloud or no cloud I think...

        I've been meaning to ask someone about this. Is OwnCloud something that someone who's kind of a moron could set up on their own server? Asking for a friend.

        Maybe not a moron, I mean, I've set up Apache and a media server, and I can read instructions when I'm sober. I just worry that I'll do something wrong and end up syncing my data with some Estonian hackers by mistake.

        • by Anonymous Coward

          If you've managed to set up an Apache server, you've got enough prerequisite skill to be able to install OwnCloud. I set it up once and it works, kinda, but it's not really as slick or robust as something like Dropbox. It's still a fairly immature FOSS product with not much in the way of paid development and it definitely shows at times in terms of usability and performance.

          It's great fun to roll your own at times, but you'll always be behind the pros who do this for a living and have worked out all the kin

        • by Junta ( 36770 ) on Wednesday October 22, 2014 @11:07PM (#48209799)

          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.

          • Seafile. Got it. Thank you.

          • Unless I'm misreading something, Seafile seems to just do file sharing (for which a simple WebDAV server is mostly enough). The value of owncloud (for me, at least) is that it also does contact and calendar sync, so my phone and computer always have the same data for these.
        • I found it pretty easy to set up on FreeBSD - install the owncloud, php5, and nginx packages and then a tiny bit of configuration (mostly copying and pasting from the owncloud site). The only gotcha was that the default nginx configuration doesn't know the correct MIME type for svg files, so I needed to fix that or none of the images in owncloud worked correctly.
      • There is also AeoroFS. They have a cloud option if you are willing to pay for it, but otherwise their servers are only used to tell the clients where the other computers are. It works quite well too. I use both this and BtSync.
    • Is it open source yet? There's no real point in using it if you can't even trust it does what they say it does...

      I can trust a company even if a program is not open source.

  • I wonder how the speed compares with OwnCloud.
    • If the OwnCloud server is on the same LAN as the laptops, I bet it is the same speed or faster than Sync.

      If off-site from the server, I doubt the OwnCloud clients are smart enough to know a friendly computer is on the same LAN to share already downloaded chunks.

      Which I might add is the only advantage to Bittorrent Sync. The technology only provides an increase in speed if one of the clients on the LAN has pieces of data already downloaded so the Internet connection is not as necessary. If neither comput
      • by suutar ( 1860506 )

        I'm not certain, but it's quite possible that the server they're both downloading from is smart enough to say "Hmm. I have two clients who want the same thing and have none of it. Let's try sending them different blocks and see if they can share between themselves; if they can, I only have to send each block once instead of twice."

        • by suutar ( 1860506 )

          (Speaking of BTSync, I was. That was a standard optimization for seeding, to try to get swarm members to get stuff from each other instead of slamming the seed.)

        • The protocol should do that in any case.
    • Just like Bittorrent sync, its highly dependent on your setup. If you run Owncloud on your home router with 1M uplink, your speed is that small. If you run your owncloud on a server with a gigabit uplink, and use google fiber, and you have an SSD in your owncloud server, you might get faster speeds.

    • OwnCloud is a WebDAV based system. It's inherently bloated, but it works. Setting it up your own web server is a requirement (or purchasing web hosting somewhere, but then the trust/security goes out the window).
      Google Drive, Dropbox, Onedrive, OwnCloud all require storing your data elsewhere.

      BT Sync only syncs data across your devices. It does it really well, utilizing Bittorrent protocols and DHT. It's actually a very useful tool. I use it all the time.

  • They compared the transfers between two laptops on the same LAN using a direct P2P client (BitTorrent Sync) and several Internet-reliant sync options, finding the direct file copy was faster. No, duh.

    In other news, you spend less time on an airplane when you take a staycation.
    • Re: (Score:2, Interesting)

      by AceJohnny ( 253840 )

      Actually, while they indeed compared two computers on the same LAN, they also included a computer on the internet. Furthermore, One of Dropbox's touted features is that it's able to detect and use peers on a LAN to avoid the unneecssary round trip through the cloud. I don't know about Google Drive, but judging by the results I suspect they can do the same.

      And, more importantly, they compared the other clients on the same setup.

      How you got modded "+4 insightful" is beyond me.

      • by MatthiasF ( 1853064 ) on Wednesday October 22, 2014 @07:41PM (#48208593)
        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... [bittorrent.com]
    • They compared the transfers between two laptops on the same LAN

      a) we don't know whether the two laptops could talk to each other across the LAN - in fact without evidence to the contrary I'd assume they couldn't
      b) Dropbox will sync across the LAN if it can.

      In any case, I'm not sure the LAN/WAN distinction is too relevant here, given that they were using 1gb/s internet connection.

      • a.) Yes, we do because the blog post says as such.
        b.) True, and that is why they intentionally nerfed the Dropbox test by creating a new random file to not only avoid "deduplication" as they say, but the LAN Sync being available as well (which they do not admit).

        RTFA:
        http://blog.bittorrent.com/201... [bittorrent.com]
        • a.) Yes, we do because the blog post says as such.

          I don't think it's at all clear.

          The company transferred a 1.36 GB MP4 video clip between two Apple MacBook Pros using [...] the Internet connection at its headquarters.

          Sync’s time might seem ridiculously low, almost as if the Internet wasn’t involved at all. You have to remember, however, that BitTorrent’s headquarters has a ridiculous fast connection both downstream and upstream.

          That implies that the LAN wasn't involved, although it's not very clearly stated.

          In any case the blogger repeated the test over the internet and got similar results.

  • Trickle (Score:4, Informative)

    by Luthair ( 847766 ) on Wednesday October 22, 2014 @06:21PM (#48207991)

    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: (Score:2, Redundant)

      Well, quite:

      More specifically, the company conducted a test that shows Sync destroys Google Drive, Microsoft’s OneDrive, and Dropbox.

      And your internet connection at the same time.

    • Re:Trickle (Score:5, Informative)

      by Bengie ( 1121981 ) on Wednesday October 22, 2014 @07:25PM (#48208469)
      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.
  • You could also install an FTP server on one machine, and log into it from the other, type 'bin', and 'get'. Frankly, this particular feature has been available since the 1980s.

    What will they think of next? Remote desktop? It was called X-windows in the 1980s.

    Kids these days think they invented sex.

    • by Anonymous Coward on Wednesday October 22, 2014 @06:29PM (#48208055)

      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.

      • Touche'. Still, I'm amazed that there's a company called logmein that provides remote desktop service on the internet, and that (get this) it works by taking over the host computer's mouse and display! On X-windows (yes, I know) the computer you're logging into (the client) isn't affected visually; the displayed windows all exist as separate entities on the computer requesting the connection (ie the "display server"). Surely that makes a heck of a lot more sense.
    • by Bengie ( 1121981 )
      Let me know how well FTP scales as you add more nodes, and how it allows you to keep your data separate from other people's data while still allowing you to use their node for storage.
    • by Cramer ( 69040 )

      Actually, it's spelled rsync

  • by gQuigs ( 913879 ) on Wednesday October 22, 2014 @06:24PM (#48208019) Homepage

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

  • by Arterion ( 941661 ) on Wednesday October 22, 2014 @06:33PM (#48208071)

    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.

    • They copied some data across a local network.

      I don't think they did, or at least it's implied - though not very clearly - that they didn't. In any case, the internet connection was 1gb/s, which is practically LAN speed with their gigabit adapters.

      The article's author did a test over the internet and also found that Bittorrent beat the others - but then, the others are probably designed to be more considerate to your internet connection and not clog up your tubes.

      • No, they literally copied over the LAN and are intentionally being vague to throw people off that fact. The original Sync blog post did not use Sync across the Internet but the Venturebeat author did disclose sharing across the Internet and stated:

        "The transfer process was much longer. Times were in the double digit minutes, and largely depended on what connections my friends had."

        In other words, in real-world scenario using the Internet, Bittorrent's Sync was not any faster than the times posted for th
        • Wait, why didn't you include this section?

          "Yet it’s worth noting that Google Drive, OneDrive, and Dropbox still performed worse. They were limited by the same download bandwidth, but the upload section of the process was notably much slower (many ISPs worldwide offer much slower upload speeds than download speeds)."

          So VB's test still gives the prize to sync. It's a bit weird that they didn't publish any times, though.

          Anyway, I'm not saying Sync is obviously better, but your quote misses context that's

        • by adolf ( 21054 )

          Indeed.

          To further muddy the waters, DropBox supports (under Windows, at least) what it calls "LAN sync," with the goal of having data traverse LAN-WAN only once, no matter how many LAN clients want that data.

          I do not know if it is default behavior. But I've seen it work just fine.

          • You think that would be a standard feature, but apparently it bears special mention.

            I miss the older Foldershare then Live Mesh for that very reason. I think it might have been before "cloud" was a buzzword, and folks still thought about networks and file storage in a traditional way.

            Skydive came out and I was fine with the giveth, but then was the taketh away. I remember being excited about the Live Framework developer API. The ideas presented don't seem especially innovative at the end of 2014, but they

    • Dropbox, at least, can do LAN syncing between devices. Of course, I didn't read the article, so I have no clue if they had it enabled on the computers so that it could be used, but based on the results, I'd doubt they did.

    • 33 MB/s is pretty good even for a LAN link. But I think for most users, this may be pretty much irrelevant because for most people, the bottleneck is between your modem and your ISP.

  • The company transferred a 1.36 GB MP4 video clip between two Apple MacBook Pros using two Apple Thunderbolt to Gigabit Ethernet Adapters

    So they're using Apple hardware, but never tested the "new and improved" iCloud Drive?

    I guess that was probably not released when they started their test.... I bet it would be equally slow though (especially since I think that part of iCloud actually runs on Azure).

  • All this has done is catalog what the bandwidth caps for the various cloud services are. The article itself admits that. BitTorrent performance is completely irrelevant.
    A relevant comparison would be against other peer-to-peer transfer utilities like scp and rsync (w/ and w/o -z).

  • by Anonymous Coward

    I've been using btsync to share my plex data elsewhere for backups. It works well, but what I've noticed is it slows down a lot when syncing more and more data.

    It started out at 60 or so megabytes a second from a 10TB volume to an empty directory on a system on the local lan. After it passed a few TB, it slowed down to 40 megabytes a second. The last couple of TB took a long while as the transfer was down to about 10 megabytes a second.

    This is still acceptable, because my outbound internet connection isn'

  • Infinit is advertising a x23 speed increase on Dropbox on a 2GB file: https://infinit.io/ [infinit.io] No comparison with btsync though.
  • To out shit products scraping the bottom of the barrel
  • Encrypted node (Score:3, Interesting)

    by chrisvdb ( 149510 ) on Wednesday October 22, 2014 @09:03PM (#48209129)

    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.

    • I have been using bittorrent sync for about the same amount of time, and the thing that is killing me is that it makes no effort to detect and warn when a file has been modified on multiple computer since the last sync. It just chooses the one that was modified most recently, and silently overwrites the other one. It does create a temporary archive backup of the modified file that was overwritten, but by the time you noticed you have lost data, it can be very difficult to wade through all the archive files

  • BTSync uses a string to connect computers and then sync files. How safe is that? I could start a script that tries to find these strings. If I find them, I can sync all files just like that. While that string is probably more unique than a username / password combination used on Dropbox, I guess Dropbox will see it when there are many failed tries on one username, or many failed tries from one IP. If your just guessing username and password, you can of course change usernames continuously, to avoid testing

    • by pavon ( 30274 )

      Even if BTSync were to process one connection string per CPU clock cycle, it would still take 1e20 years to try all the possible 20-character Base64 strings that BTSync uses by default. If you choose a longer string, then it will take even more time. In otherwords, the standard strings have 120 bits of entropy, and you can increase that to up to 240 bits. This is less than is typically used for encryption these days, but btsync doesn't have to deal with offline attacks.

      Rather than key size, I would be more

    • by omems ( 1869410 )
      It's also my understanding that with the newest version, you can specify trusted clients with which to sync, so not just anyone can connect.
      Although, now that I think about it, I'm not sure that couldn't be spoofed if you knew a little bit about the other person.

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...