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...