W dniu 31.01.2023 o 19:31, Paul Mather pisze:
While playing with different mod_cc(4) might bring some improvement, to get a
real boost I'd suggest enabling tcp_rack(4) if feasible.
I am interested in trying this out, but believe it is more feasible in my case
for the -STABLE and -CURRENT systems I am using, not so much for the -RELEASE
systems that are kept up to date via binary freebsd-update updates. My reading
of the tcp_rack(4) man page is that you have to build a custom kernel as,
unlike the cc_* congestion control algorithms, the loadable tcp_rack module is
not built by default. Is that an accurate reading?
Yes, this gift from Netflix is probably better suited for -STABLE and
-CURRENT as easier to set up there. There is an excellent, up-to-date
article about it by Klara Systems writers[1]. From my experience
tcp_rack(4) is well suited for congested, lossy or redundant network
paths where loses, duplicated packets or races between packets occur.
Not a panacea, but very performant TCP stack based on the _fair_
algorithm. In some instances, it might help you to saturate the
bandwidth of the link. TCP algo can be loaded/unloaded/changed on the
fly. In FreeBSD 14-CURRENT you can change it on an active socket with
tcpsso(8) utility, in FreeBSD 12 and 13 you have to restart the app
bound to the socket.
Please feel free to play with TCP stacks and congestion algos with the
help of benchmarks/iperf3 to find out what prevents the link from being
saturated and give us some feedback here.
[1] https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/
Cheers
--
Marek Zarychta
