Syncthing is extremly slow!

Dear Syncthing developers. After finally switching from BitTorrent Sync to Syncthing, one thing annoyes me: BitTorrent Sync could sync up to 11 MB/s between the two devices described below. Syncthing is stuck with about 1,7 MB/s. The CPU-load is constantly low (about 10% each). From time to time, my devices do not sync at all. I have also tried to install Linux on my Laptop too, but this doesn’t make a difference. Compression is also turned off(helped a little bit). From what I have read in the forums, this is a widely seen issue(Raspberry Pi (2/3) does have this issue, too, possibly an ARM issue?). If I can help you by providing logs, etc, please let me know. it would be great if you can fix this. Yours faithfully, TheJack

#Information: ##Banana Pi M3: Syncthing Version: v0.14.5 OS Version: Linux Ubuntu 16.04.1 ##Laptop: Syncthing Version: v0.14.5 x64 OS Version: Windows 10 x64/Linux Fedora 24 ##Additional Information: ~87600 objects ~262 GiB

How do you check the CPU usage? If the value in the syncthing GUI on the Banana Pi is at around 10% that could mean one core at almost 100% as it seems to have 8 cores according to a quick search.

Another thing is that you could be limited by IO depending on where your database and files are and if you are currently syncing mainly small files. (iotop you show that)

1 Like

I have checked it again with htop, and the CPU load per core is around 10%, but only beacause I have tweaked it a little bit with ionice,nice and GOMAXPROCS. Without tweaking, however, the CPU load per core was around 6%. IO cannot be the problem, because it’s the same setup as with BitTorrent Sync(there I get 11 MB/s).

Hope you can help me, Jack

Checked these things?

Yes. The devices are connected via a direct IPv6 Connection and the CPU load is constantly low.

Maybe the statistics may help you fixing this:

Honestly I suspect you are CPU limited by the crypto and not properly measuring the CPU utilization. TLS isn’t easily parallelizable so if you’re seeing an even 10% per core, then you are in fact most likely at 100% on one core and the system is just switching the process around.

But don’t take my word for it, we can profile this. Grab a CPU profile while it’s syncing at the speed you’re reaching, using the following instructions and we can figure out what’s going on:

Here is the CPU Profile:

Is the ARM Version provided in the repo’s an ARMv7 one? Thanks for looking into this.

Here’s a decoded profile in graphical form:

There’s something wrong with the interpretation at deep levels of the stack (possibly because I’m not on ARM, not that it should matter) - the stuff implicating package tabwriter and ignore parsing in the trace with 5s of CPU time is clearly (as in when comparing to the actual code) incorrect. However the top level things make sense:

So in summary, decrypting and hashing. Sorry. :confused:

OK. That makes me wonder how BitTorrent Sync does this. From what I have seen, they are using AES, too( Perhaps they are using some sort of hardware acceleration?

Possibly, I have no idea. Our (Go’s) AES implementation is fairly crappy on ARM unfortunately, using hardware acceleration only on amd64.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.