I’ve been troubleshooting extremely slow transfer speeds, and I’ve finally pinpointed it to block indexing. Disabling it makes speeds go up from 350kB/s to the expected 16MB/s. This is when transferring a large set of 8MiB files (created with random data for testing). The endpoints are running 4.5GHz Skylake and 3.7GHz Zen3. The former seems to be slightly faster despite the latter having much more cores. And sure enough, with the slow transfers, only a couple of CPU cores are maxed out.
Even after disabling indexing on most of my shares, so that the total amount of block indexes to compare is smaller, the speed with block indexing on the share doing the transfer is still on the order of 800kB/s.
The conclusion is to just not use block indexing. But from my understanding, that’s exactly the feature that allows Syncthing to “rename/move” files. Is there really no other way for Syncthing to detect renames and moves? The shares where renames and moves are regular enough still contain about 300k files and 1TiB, which appears to be too much for Syncthing’s block indexing to handle at any reasonable speed. Do I just have to live with re-transferring a file when a simple rename happens?
Another option would be to disable block comparisons between shares, so each share has its own private pool of block indexes. This would greatly reduce the number of comparisons. But Syncthing doesn’t appear to have this option.