I have a home LAN with 7 hosts running syncthing. Many are on wireless. 2 are always on wired.
Here’s my thought: when several wireless hosts are all syncing a large amount of data, they’ll tend to download from each other and other wireless hosts as well as from the wired hosts, as is the design of syncthing.
The problem is that a wireless host can download twice as fast from a wired host as from another wireless host, because in the latter the limited wireless bandwidth is used twice. Multi-band access points mitigate this but the same issue arises again with a sufficient number of wireless hosts downloading from each other. It also gets worse; in the case of a single band, for example, if host B on wireless is downloading chunks from host C on wireless, and host C is also downloading from host B, then both are consuming precious wireless bandwith sending data to the other, when a wired host would suffice, extend this to NxN and downloads can be significantly slowed compared to preferring wired nodes. If I understand, B and C will also be downloading from wired host A as well as from each other, but the extra utilization of the wireless bandwidth also slows down that connection as well.
First, is there anything already handling, to any degree, this issue? Perhaps dropping slow rate connections in preference to higher rate connections? I haven’t been able to find anything in the forums or the issue tracker discussing this.
Second, potential solutions. I came across a soapbox today saying to always segregate your wireless from your wired in different subnets. I don’t think I agree about always, but there was a compelling reason offered why you would want to do that: adding a higher metric on the wireless subnet (including and perhaps even higher for wireless-to-wireless, not sure if that’s possible). This may solve the other issue I’ve seen in the forums where a host does not prefer its own wired interface (I have seen the same issue, not sure why it happens with syncthing and not with other programs like rsync). I’m not sure this would solve the issue ITT, without syncthing actively looking at the metrics to a potential peer and actively choosing not to sync from the higher metric. Of course you would not want to do this over the wan (except maybe with extreme metric differences? Or perhaps when a ‘sufficient’ number of lower metric nodes have already been peered?) So at first glance it seems like a “LAN only” check. The assumption being if the administrator of a lan has purposely put a higher metric on a route between hosts, that it is to NOT be used unless the lower metrics are not available (or IOW use only the lowest metric available, however many hosts can be reached with that metric).
The other idea I had was to have syncthing empirically test performance. Start with a single peer and observe the dl rate. Then add another peer, if the total dl rate goes down instead of up, drop the peer again and try adding another, etc (perhaps trading peers as well to see if one is faster alone than the other). This solution seems more convoluted, though the first solution requires a somewhat advanced LAN setup, but may be reasonable to expect in the situations where this becomes a large issue.