On Jan 30, 2023, at 6:30 PM, Matt Garber <[email protected]> wrote:
> >> > Any help/insight is gratefully appreciated. >> > >> > Cheers, >> > >> > Paul. >> > >> >> sysctl net.inet.tcp.cc.algorithm=htcp >> >> I would set "htcp" on the server and home computer to improve through in >> your type of situation. > > > There may be other FreeBSD sysctls that have bad defaults in this scenario > and could be better tuned, but I doubt changing the CC algorithm at this > point is the problem — at least not so much a problem that’s causing > throughput to be reduced so drastically. Happy to be wrong if that does help > things quickly and easily, though. Changing the CC algorithm doesn't affect speeds greatly in my case. For example, changing to HTCP on one of the remote FreeBSD systems improves speeds somewhat, but not to put them on a par with what I get from the Linux systems. I can easily get 19--20 MB/s on a 100 MB download from Linux but I've never managed to get above 10 MB/s at all from the remote FreeBSD systems, even when switching to HTCP. In addition, the Linux download quickly gets up to max speed but FreeBSD is slower to increase speeds and is more variable in the speeds throughout the entire download. > (Since OP mentioned that FreeBSD CC was set to CUBIC, that would match what > the Linux boxes are using by default, too, unless they’ve been changed to > something newer like BBR… so seems like CUBIC *should* be performing fine on > this WAN link, and the difference is something else.) I suspect the same thing, too, i.e., it is implementation/specific configuration details that differ between FreeBSD and Linux, especially when they are both set to use CUBIC. I checked on one of the Linux systems (Rocky Linux 9) and verified it defaults to CUBIC (net.ipv4.tcp_congestion_control = cubic). Cheers, Paul.
