Tu as beaucoup de pertes (à voir si ça peut venir de toi, ou si c'est côté Orange).

Avec le même serveur (en IPv4 comme toi, mais en IPv6 c'est pareil) :
~ ᐅ iperf3 -4 -c speedtest.milkywan.fr -p 9201 -t 10
Connecting to host speedtest.milkywan.fr, port 9201
[  5] local 192.168.2.22 port 46400 connected to 80.67.167.93 port 9201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  89.4 MBytes   749 Mbits/sec   65    922 KBytes
[  5]   1.00-2.00   sec  97.0 MBytes   814 Mbits/sec    0   1000 KBytes
[  5]   2.00-3.00   sec  95.8 MBytes   803 Mbits/sec    0   1.05 MBytes
[  5]   3.00-4.00   sec  95.8 MBytes   803 Mbits/sec    0   1.11 MBytes
[  5]   4.00-5.00   sec  97.0 MBytes   814 Mbits/sec    0   1.17 MBytes
[  5]   5.00-6.00   sec  95.8 MBytes   803 Mbits/sec    0   1.23 MBytes
[  5]   6.00-7.00   sec  97.0 MBytes   814 Mbits/sec    0   1.29 MBytes
[  5]   7.00-8.00   sec  95.8 MBytes   803 Mbits/sec    0   1.34 MBytes
[  5]   8.00-9.00   sec  95.9 MBytes   804 Mbits/sec    0   1.39 MBytes
[  5]   9.00-10.00  sec  97.0 MBytes   814 Mbits/sec    0   1.44 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   956 MBytes   802 Mbits/sec   65             sender
[  5]   0.00-10.05  sec   954 MBytes   797 Mbits/sec                  receiverLà j'ai pile les 800M de mon profil, et surtout uniquement quelques retry lors de la première seconde et plus rien après.

En changeant l'algo de congestion de bar à cubic (sysctl -w net.ipv4.tcp_congestion_control=cubic), plus de retry, enfin juste le premier.

# iperf3 -c speedtest.milkywan.fr -p 9201 -t 10
Connecting to host speedtest.milkywan.fr, port 9201
[  5] local 192.168.2.254 port 37704 connected to 80.67.167.93 port 9201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  75.9 MBytes   636 Mbits/sec  1358   2.17 MBytes
[  5]   1.00-2.00   sec  78.5 MBytes   659 Mbits/sec    0   2.28 MBytes
[  5]   2.00-3.00   sec  86.6 MBytes   727 Mbits/sec    0   2.37 MBytes
[  5]   3.00-4.00   sec  86.1 MBytes   722 Mbits/sec    0   2.43 MBytes
[  5]   4.00-5.00   sec  86.5 MBytes   726 Mbits/sec    0   2.48 MBytes
[  5]   5.00-6.00   sec  86.1 MBytes   722 Mbits/sec    0   2.50 MBytes
[  5]   6.00-7.00   sec  86.2 MBytes   724 Mbits/sec    0   2.52 MBytes
[  5]   7.00-8.00   sec  94.1 MBytes   789 Mbits/sec    0   2.53 MBytes
[  5]   8.00-9.00   sec  86.1 MBytes   722 Mbits/sec    0   2.53 MBytes
[  5]   9.00-10.00  sec  94.4 MBytes   792 Mbits/sec    0   2.53 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   861 MBytes   722 Mbits/sec  1358             sender
[  5]   0.00-10.04  sec   840 MBytes   702 Mbits/sec                  receiver

iperf Done.

si je reviens à bbr (sysctl -w net.ipv4.tcp_congestion_control=bbr), les retries reviennent.

Je fais les test à partir d'une machine (linux) connecté à unroute mikrotik (ccr2116) qui je crois est en cubic (ou en tout cas pas en bbr). Je pense que cela doit venir de là.

Le routeur n'intervient pas, l'algo de congestion est celui de la machine qui envoie.

En BBR, c'est effectivement peu étonnant d'avoir des retransmissions.
Mais même en Cubic tu en as beaucoup plus que moi, peut-être que tu as des paramètres qui entrainent une montée en débit plus rapide.

ok merci

Ne pas utilisé BBR, ce n'est pas fait pour un réseau normal, mais de stream.

Tu conseilles quoi ? Cubic ?
Tu peux développer le pourquoi pas BBR stp ?

Tu conseilles quoi ? Cubic ?
Tu peux développer le pourquoi pas BBR stp ?

Bah je l'ai indiqué dans ma précédente réponse. Le BBR c'est fait pour des network qui stream des flux video ou de la data. En tout cas pour la v2.

belle progression de la fibre xgs-pon d'orange en région parisienne pour la fin d'année 2024