I entirely agree that multiple connections shouldn't actually be necessary for speed, but they help in multiple situations (long-distance transfers, same DC between servers, NFS), and it's not just about amortizing per-file setup overhead.

There is some info on the optimizations in the docs, but I agree that a more complete technical explanation of all the things syq does could be useful. I will work on one. On the other hand, I also tried hard to make it just go fast without needing the user to understand why it is fast or tune anything. For instance, the number of connections is auto-tuned by default.

> There is some info on the optimizations in the docs, but I agree that a more complete technical explanation of all the things syq does could be useful

First, thank you for taking the feedback :)

To be clear, I'm focusing on the first thing you should be telling users. It seems that, as a CLI program, the target audience of this tool is fairly technical users who are likely already familiar with SSH, rsync, and everything. As demonstrated in this thread, your first communication task is to convince them why it's worth their time to use your tool, considering they're probably satisfied with the pre-existing ones (or a replacement would already exist!).

My point is, explaining why it's better/faster than rsync shouldn't be buried in the docs. It should be a paragraph on the front page.

Hope this helps, and keep it up. HN is a rough audience to go public on ^^;

Multiple connections totally help. At a previous job, we drove rsync with GNU parallel, then did a final catch-all pass with rsync, and that divided transfer time for about 600GB by a factor of 4.