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.
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.
There's no real point in using it if you can't even trust it does what they say it does...
I wonder how the speed compares with OwnCloud.
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.
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.
is https://ind.ie/pulse/ (was SyncThing).
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.
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.
"That which does not kill us makes us stranger." -Trevor Goodchild
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).
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.
I don't understand why everybody is like, "err, btsync sucks until you show us the source!" The statements about closed source are true, but all the other major options are closed source as well so it's not a good thing to criticize btsync on!
I tried it out, and I liked it very much. I hit two problems, one of which is easier to solve:
1) no versioning implemented. The client could get really smart about versioning in a later update. This is primarily why I use dropbox, even on a machine where the files stay local.
2) my work blocks torrent traffic.
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).
I think our meetings would be a lot less functional that way though.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
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't that fast, but it does make me wonder about the scalability of btsync. Still, btsync is a winner in my book. It just works.
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.
Infinit is advertising a x23 speed increase on Dropbox on a 2GB file: https://infinit.io/ No comparison with btsync though.
Actually, it's spelled rsync
To out shit products scraping the bottom of the barrel
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 on different computers and figure out which ones need to be merged. The resolution to conflicts will always have to be a manual process, but the sooner you know that a conflict occured the easier it is to resolve.
I've lost track of how many password resets I have had to do because I lost a newly randomly generated password saved to my keypass database, synced across computers.
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.
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 concerned about whether the client potentially leaks data through timing attacks, or any MITM/sniffing attacks that speed up the cracking faster than brute force.
As I recall, it scaled really well in it's prime. Many people setup their own FTP servers for their own uses. It supported seperation of users on systems through credential logins, file permissions etc.
I didn't like FTP.
Change is certain; progress is not obligatory.
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.
When you asked your work's IT department why your work has chosen to block BitTorrent Sync traffic and has chosen not to block Dropbox traffic, what reply did you get?
We're a small company with just one overworked IT guy, so I don't think he was actively checking the logs and monitoring which computers were trying to access torrent ports. I chose not to draw attention to the fact that I was trying to torrent files (regardless of the justification), let alone be a person who was seen as complaining about it. That would raise eyebrows and be sent up the flagpole.
I ended up using Sync.com, which is a dropbox competitor based in Canada. I'm not naïve enough to think that NSA doesn't have access to their shizz, but at least they don't have Condi on the board. More of a protest vote on my part more than anything.
What if you don't trust root on the FTP server? Sync keeps you safe from that case, with no extra work on your end.
If I didn't trust myself, I don't see how Sync would help.
Change is certain; progress is not obligatory.
Sync supports storing your data on untrusted nodes because of transparent encryption. You even have the option to share your data with certain other people in read-only or read-write. Well, it's designed to support that. I'm not sure if they've enabled it in the interface yet.
I'm being pedantic now for the hell of it...
So does FTP, anyone can run FTP.
So does FTP.
So does FTP.
I still don't like FTP.
Change is certain; progress is not obligatory.