4Gb test to B2 dupliCACY v. dupliCITY

Does duplicacy have some throttling by default? I did two 4Gb tests today, the first (green circle below) using dupliCITY, the more recent (red circle below) using dupliCACY. It looks like duplliCITY is using quite a bit more available bandwidth and gets the job done much faster. Is there anything I can do in my config to speed things up? This post notes
“Performance wise, Duplicacy is about 2-3 times faster than Duplicati with the default settings”

DupliCITY = green circle
DupliCACY = red circle

What is the backend storage? What is the connection protocol?

I would first measure the bottleneck: is it target storage IO latency? Is it CPU on the host? IO latency on the host? Network/bufferbloat?

Otherwise it’s would be a wild guess. Like “try backing up with multiple threads”

Both of these are to Backblaze B2. Some of those data points I don’t have access to. As for the source I’m confident there isn’t cpu bound or io issue.
I also tested the same backup with Duplicacy to S3. The speed was about the same as that in the green circle --which I think is maximizing my available bandwidth.
I wonder then, ‘does b2 throttle connections?’ I’ll try this again soon to see if the performance is the same.

Try adding -threads 10 option to your backup command. I don’t know if the other tool uses multithreaded upload by default; B2 is expected to trabsfer single thread to about 10megabit and you are expected to upload in multiple threads if you want faster performance. Don’t quote me on this — I don’t remember where I read that but it matches with my observations.

I don’t think B2 throttles intentionally — it’s in their best interest to let you upload as much as possible as quickly as possible but there could have been a network congestion for example somewhere between you and B2 that wasn’t there when you were testing with the other tool. Too many variables…

You can also add -dry-run flag — Duplicacy will do everything except actually uploading the data/changing anything on the server — this should help distinguish network issues form local ones.