I am currently running syncthing on a Raspberry Pi B+, but performance is fairly bad. Scans are CPU limited and keep the HDDs spinning for over an hour and transfer speeds are limited to <5Mbps. So I would like to know if the new Raspberry Pi would give a significant performance boost.
Is anyone running syncthing on the new Raspberry Pi 2? If so, what are transfer rates do you get?
Well I’ve just read an article about it here: http://www.bbc.co.uk/news/technology-31088908
Going by what it says there, it’s now fitted with a quad core CPU and 1GB RAM. They estimate applications will run up to 6 times faster.
Thanks for the reply, but I’ve seen the specification. What is not clear is how this will affect transfer rates I get. I highly doubt that I can multiply my previous rate by 6.
I doubt that too, but at a guess I think you would double it. Depending on the class of memory card you use or type of external drive.
Guess we will have to wait until someone purchases one 
I use a banana Pi. It is not an performance Monster but performs quite well. It is a “central” syncthing node which collects files to backup from Clients (computers and mobile devices). Therefore I use syncthing which now works greak. The backup itself is “mirrored” back to a computer Arichv is about 300 Gig in size. Only thing I’m wondering about that the transfer is never faster than 2 MB/s. (iperf shows 500+ Mbit/s). First I used an Raspberry Pi B which was completely overloaded.
Interesting, I have previously considered getting a banana pi, but it sounds like transfer is no faster than on my raspberry pi B+. I assume you have compression turned off?
The SATA port on the banana pi is nice, but I wish it had two for mirroring.
because Syncthing compresses/encrypts or decompresses/decrypts the data while iperf just sends test data
Compression was on. I turned it now of. lets see the difference.
I don’t think this is the core problem. scp does 12 MB/s. However - I’m not complaining about speed. Actually syncthing right works very very good. Congrats and many thanks to the developers.
I am using a Raspberry PI 2 after my original pi failed to index my ~1TB of files ( approx ~32k files) despite being given weeks to do so and reducing the scan interval to once a day. The Pi 2 has indexed in today (once I installed the armv7 version). So good news on the indexing front - now to test file transfer speed…
I filed a bug report after comparing Syncthing’s transfer rate to BTSync between a Linux desktop and an Odroid-C1. You can find my results here:
I have been running BTSync on many Raspberry Pi Model Bs for well over a year and they were no longer able to keep up. The Odroid-C1 easily solved the BTSync performance problems. Typical loads were 5 to 8 are now well below 1 most of the time. I’m sure the RPi2 would have also solved my problem.
I was not able to get Syncthing to work on the RPi Model B. It runs great on the Odroid-C1 although as you can see from my bug report it’s about half the speed of BTSync. This is on a LAN, I have not done speed tests over the internet yet.
The Odroid-C1 has GB Ethernet and it does not use the USB bus so for my system it’s probably a better match since I’m using USB hard disks for backup purposes. This may mean that Syncthing may be a little faster on the Odroid-C1 than on the RPi2 but I do not have an RPi2 to compare it to.
I’m still relying on BTSync for most of my backup systems. Until they fix the bug in my report the performance issue is a secondary concern.
Thanks for the info CoupeWare.
Your concern about the usb bus being used for ethernet on the pi suggests that you believe the CPU is not the bottleneck for transfer speeds for the Odroid-C1, is that the case?
Were the 20 Mbps and 40 Mbps on the Odroid or the i7 machine?
The transfers were between and Odroid-C1 and an i7 machine.
Most of my experience is with BTSync, not Syncthing. I’m not sure why Syncthing is half the speed of BTSync. I’m not sure where the bottleneck is once the CPU is no longer a problem. It does appear that Syncthing uses less CPU and RAM but I haven’t done enough testing to be sure. It just seems that using the USB bus for both network and hard disk access may slow things down. Maybe I’ll buy an RPi2 and see for myself. Some of my systems use USB WiFi adapters so the Odroid-C1 does not have an advantage there. I may setup a test with Syncthing using the WiFi adapter and compare it to the Ethernet numbers that I already have to see if the networking over the USB bus does slow things down. I’ll let you know if I do this.
I failed to mention that the USB hard disks are encrypted using LUKS / dmcrypt. This definitely adds to the CPU load with any sync operation. I first tried the dual core Banana Pi and it was better but still not great. The quad core Odroid-C1 is far better.
I think the added RAM really helps BTSync. Not sure it matters as much with Syncthing since it appears to use much less RAM.
There are many ways to compare syncing software and I only measured transfer speed over a LAN with lots of small files and a few large files. One annoyance I have with BTSync is that it sometimes takes many hours (or a day or longer) for it to start transferring files that have been added to a system which can quickly negates the transfer speed advantage. The backup systems have 2 TB of files on them so the delay may be due to the number of files. Not sure how Syncthing would deal with changes on these systems.
The Odroid-C1 meets my needs and allows me to run both BTSync and Syncthing on the same system. If Syncthing fixes my bug and seems stable enough I may start moving my cloud backup systems over to Syncthing. For now I’m just hoping BTSync doesn’t get any worse. Every upgrade seemed to slow my systems down.
I have just synced some files and I’m seeing very poor transfer rate on the GUI (using solely the gui on my NAS rather than the raspberry p iGUI) - 850 KiBs. THese are 350MB video files syncing across a wired home network.
CPU/RAM footprint has already been discussed here, and and issue opened here. To make a long story short, SyncThing is less efficient than BTSync.
Plus, having the web ui open can cause slow transfer rates.
Possibly. It also does more, at least in terms of encryption and security, and the rest we don’t know since the BTSync protocol is a black box.
The approach on the peer connection is different, but that will probably change with the version 2.0 of BTSync. BTSync is apparently implementing the same scheme, with user IDs and shares. BTSync allows encrypted nodes, as well as R/W and Read Only nodes, with is not possible with ST.
Performance wise, I assure you that BTSync is better. Wayyyyy better. Transfer rates are twice the transfer rates of ST on LAN (15-20 MB/s for ST, 40-45 MB/s for BTSync), even with good machines (Core i3 and i5). Moreover, the exchange of the entire list of files at the connection is really slowing down the sync process. For example, I have a folder with 35K files, shared with a machine outside of the LAN. At every connection, ST sends ~130 MB @ 280 kB/s just to list the files, which takes a bit less than 10 minutes.
I can live with it, ST has other interesting features, is stable, reliable, open source, secure… But it cannot compete with BTSync where scalability and performances are necessary.
