y'a des bizarreries avec IPerf3 et Windows:
serveur: Linux IPerf3 3.7 avec
net.core.rmem_default = 212992
net.core.rmem_max = 212992
net.core.wmem_default = 212992
net.core.wmem_max = 212992
net.ipv4.tcp_rmem = 4096 131072 6291456
net.ipv4.tcp_wmem = 4096 16384 4194304
(donc les réglages par défaut d'archlinux)
client : Windows 10 pro fraichement installé et mis a jour.
Lien LAN entre les 2 a 10 Gbits, latence < 1ms donc.
Les deux sont en bare metal sans virtualization.
IPerf3 :
Windows -> Linux : 3 Gbps
Linux -> Windows : 8 Gbps
Goben:
Windows -> Linux : 9.4 Gbps
Linux -> Windows : 9.4 Gbps
Transfert HTTP avec
serveur web maison tournant dans le serveur Linux(mesures débit au dessus de HTTP)
avec
Curl: Linux -> Windows : 9.15 Gbps
Avec
Wget: Linux -> Windows : 5.28 Gbps
(je n'ai pas encore écrit la version avec un PUT pour tester dans l'autre sens)
Il faut ajouter l'option
-w a IPerf3 pour gagner en débit mais elle plante quand on a atteint 2x le net.core.Xmem_max du serveur (soit 425984).
IPerf3 -w 425984:
Windows -> Linux : 7.3 Gbps
Linux -> Windows : 9.4 Gbps
IPerf3 -w 425985 (+1 du max*2) donc:
le serveur affiche:
iperf3: error - socket buffer size not set correctly
quel que ce soit le sens (-R ou pas).
Du coup sans modifier un serveur Linux de base, Windows 10 ne peut envoyer a 10Gbps avec IPerf3 (pas de souci avec Goben). Wget présente des limitations en reception aussi.A priori avec -w, le client iperf3 demande au serveur IPerf3 de changer le socket buffer size meme en reception.
questions/conclusion: doit-on modifier les réglages des OS pour faire fonctionner les applications "mal écrites ?" (iperf3, wget) ou arrêter d'utiliser ces applications pour ces débits la ?