Как улучшить устойчивость TCP к неупорядоченной доставке в Linux balance-rr bonds и/или лаги циклического перебора FreeBSD?

У меня есть 3 сервера в сети, настроенные следующим образом

• А это DELL R710 под управлением Linux 5.13.19-1-pve Проксмокс VE 7.1 и имеет 4 сетевых адаптера, объединенных в баланс-рр облигация режима.
• Б это DELL R610 под управлением Linux 5.13.19-1-pve Проксмокс VE 7.1 и имеет 4 сетевых адаптера, объединенных в баланс-рр облигация режима.
• С работает DELL R710 FreeBSD 12.2-РЕЛИЗ-p1 с отставание от 8 сетевых карт в по-круговой (это дистрибутив TrueNAS).

Все сетевые карты имеют пропускную способность 1 Гбит/с.

Когда я бегу iperf3 между лезвиями Linux у меня максимальная скорость составляет около 3 Гбит / с, а окно увеличивается в среднем до ~ 300 КиБ. Однако между блейд-сервером TrueNAS (FreeBSD) и блейд-сервером Linux максимальная скорость потока TCP составляет 1,20 Гбит/с, а среднее значение окна составляет ~60 КиБ. Если я запускаю параллельные потоки (т.е. иперф3 ...-П 8) Я могу насытить связь. С другой стороны, как и ожидалось, количество повторных передач довольно велико в обоих случаях. Итак, мои вопросы,

1. Почему FreeBSD не достигает одинаковой пропускной способности, если предположительно обе они подходят к проблеме одинаково? (возможно, тут я ошибаюсь).
2. Существует ли параметр настройки или комбинация параметров, чтобы сделать стек TCP более устойчивым к нарушению порядка без запуска немедленных повторных передач? (Я смутно знаком с 3-ACK reTX, основами управления перегрузкой TCP и так далее).

Я включу сюда некоторые настройки и опции, которые я использовал во время тестирования.

• Все интерфейсы настроены на использование больших кадров (MTU 9000).
• Ящики Linux настраиваются следующим образом

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.ipv4.tcp_mem = 1638400 1638400 1638400
net.ipv4.tcp_rmem = 10240 87380 16777216
net.ipv4.tcp_rmem = 10240 87380 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_reordering = 127
net.ipv4.tcp_max_reordering = 1000
net.core.netdev_max_backlog = 10000
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_congestion_control = рено

• Коробка FreeBSD (TrueNAS Core ~= FreeNAS) настраивается следующим образом

kern.ipc.maxsockbuf=614400000
керн.ipc.somaxconn=1024
net.route.netisr_maxqlen=8192
net.inet.ip.intr_queue_maxlen=8192
net.inet.tcp.mssdflt=8948
net.inet.tcp.reass.maxqueuelen=1000
net.inet.tcp.recvbuf_inc=65536
сеть.inet.tcp.sendbuf_inc=65536
net.inet.tcp.sendbuf_max=307200000
net.inet.tcp.recvbuf_max=307200000
net.inet.tcp.recvspace=65228
net.inet.tcp.sendspace=65228
сеть.inet.tcp.minmss=536
сеть.inet.tcp.abc_l_var=52
net.inet.tcp.initcwnd_segments=52 # быстрый старт
net.inet.udp.recvspace=1048576
net.inet.udp.sendspace=1048576

Вы можете попробовать использовать большие кадры, если ваша сеть поддерживает это. Это не устраняет основную проблему запуска повторных передач TCP не по порядку.Однако, поскольку кадры Ethernet в шесть раз больше, количество пакетов уменьшается, что снижает количество событий не по порядку.

В противном случае вы должны проверить свой вариант использования, вам действительно нужно одно TCP-соединение, чтобы получить всю пропускную способность? Если между устройствами имеется несколько активных TCP-подключений, следует использовать балансировку нагрузки с учетом TCP.