Test identique réalisé à l'instant sur une connexion Free... 16% perte sur Receiver...
Cela ne veut pas dire charrette... D'autres peuvent faire le même test? Quel que soit l'opérateur, mais avec la même cible?

@vanilu76 tu n'aurais pas un problème par hasard ??  97% de pertes....t'es en wifi ?

Bonsoir,

ma contribution et aussi mon premier post sur le forum 
Test PC sous Linux en ethernet 1G

Reverse mode, remote host bouygues.testdebit.info is sending
[  5] local 192.168.2.138 port 38254 connected to 89.84.1.186 port 9222
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  98.5 MBytes   827 Mbits/sec  0.031 ms  6319/77674 (8.1%) 
[  5]   1.00-2.00   sec   107 MBytes   900 Mbits/sec  0.018 ms  0/77690 (0%) 
[  5]   2.00-3.00   sec   107 MBytes   899 Mbits/sec  0.020 ms  108/77693 (0.14%) 
[  5]   3.00-4.00   sec   107 MBytes   900 Mbits/sec  0.020 ms  0/77707 (0%) 
[  5]   4.00-5.00   sec   107 MBytes   900 Mbits/sec  0.021 ms  0/77682 (0%) 
[  5]   5.00-6.00   sec   107 MBytes   900 Mbits/sec  0.023 ms  0/77683 (0%) 
[  5]   6.00-7.00   sec   101 MBytes   847 Mbits/sec  0.044 ms  4290/77446 (5.5%) 
[  5]   7.00-8.00   sec   108 MBytes   903 Mbits/sec  0.010 ms  56/77970 (0.072%) 
[  5]   8.00-9.00   sec   107 MBytes   900 Mbits/sec  0.020 ms  0/77674 (0%) 
[  5]   9.00-10.00  sec   107 MBytes   899 Mbits/sec  0.017 ms  0/77639 (0%) 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.01  sec  1.05 GBytes   900 Mbits/sec  0.000 ms  0/777743 (0%)  sender
[  5]   0.00-10.00  sec  1.03 GBytes   887 Mbits/sec  0.017 ms  10773/776858 (1.4%)  receiver

Si je résume...
Le test étant fait en UDP, il y a un équipement dans la trajectoire qui pose problème pour ceux qui ont des pertes sensibles avec ce test...
Le receiver étant le PC qui a déclenché le test, il peut aussi poser problème ("j'arrive pas à avaler tout ce que l'on m'envoie!"), ou la box ("P'T1, ma CPU ne suit pas, parce que l'on lui en demande trop par ailleurs!"), ou un autre équipement "actif" sur la trajectoire... 

Si je résume...
Le test étant fait en UDP, il y a un équipement dans la trajectoire qui pose problème pour ceux qui ont des pertes sensibles avec ce test...
Le receiver étant le PC qui a déclenché le test, il peut aussi poser problème ("j'arrive pas à avaler tout ce que l'on m'envoie!"), ou la box ("P'T1, ma CPU ne suit pas, parce que l'on lui en demande trop par ailleurs!"), ou un autre équipement "actif" sur la trajectoire... 

Je viens de faire toute une série de tests, non pas en UDP, mais en TCP, en limitant le débit avec le -b, toujours en reverse mode, le PC étant Receiver.
Ce qui est intéressant est que IPerf3 dans ce mode indique le nombre de retry, le receiver n'ayant pas reçu correctement la trame, et demandant le renvoi.
Les test ont commencé en limitant à 900M (carte ethernet 1Gb) et tant que j'ai eu un nombre de retry significatif, j'ai fait un nouveau test, en descendant le débit...
J'ai un vieille bécane de 2014, et les résultats sont les suivants, en réduisant à chaque fois de 100M le débit:
à 900M, plus de 2000 retry, et ceux-ci on descendu très lentement, au fur et à mesure de la réduction de débit. Ils était encore à 1800 à 200M, et enfin à 100M, plus de retry, ceci de façon répétitive...
J'aurais tendance à conclure que la gestion de mon W10 avec un I7 de 2014 avec 16Go de mémoire et son chipset Ethernet intégré à la carte mère (ASUS Maximus VII Hero) ne savent pas faire plus, en exploitation "standard" (je ne suis pas en mode sans échec...)
Si ma contribution peut apporter quelque chose...

Bon la je pense que c'est clair... sur un test a 900M
1.5% de perte fibre --> Box
17% de perte Box -->  PC

Fait un iperf3 -s sur la box et laisse tourner (ça lance un serveur iperf sur ta box en mode serveur, avec le port par défaut), puis un iperf3.exe -R -c <ip LAN de la box> sur le PC client windows. Iperf permet de faire serveur aussi.