J'ai un boîtier Linux que j'utilise en tant que iperf3client, testant 2 boîtiers de serveurs Windows 2012 R2 identiques avec Broadcom BCM5721, des adaptateurs 1 Go (2 ports, mais un seul utilisé pour le test). Toutes les machines sont connectées via un seul commutateur 1Gb.
Test UDP à 300Mbit par exemple
iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192
entraîne la perte de 14% de tous les paquets envoyés (pour l'autre boîtier serveur avec exactement le même matériel, mais les pilotes NIC plus anciens, la perte est d'environ 2%), mais la perte se produit même à 50 Mbits, quoique moins sévèrement. Performances TCP à l'aide de paramètres équivalents:
iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192
donne des vitesses de transmission au nord de 800 Mbits, sans retransmissions signalées.
Le serveur est toujours démarré à l'aide des options suivantes:
iperf3 -sB192.168.30.161
Qui est à blâmer?
La boîte client Linux (matériel? Pilotes? Paramètres?)?Edit: je viens de lancer le test d'un serveur Windows à l'autre et la perte de paquets UDP à 300 Mbits était encore plus élevée, à 22%- Les boîtiers du serveur Windows (matériel? Pilote? Paramètres?)?
- Le commutateur (unique) qui connecte toutes les machines de test?
- Des câbles?
Éditer:
Maintenant, j'ai essayé l'autre direction: Windows -> Linux. Résultat: la perte de paquets est toujours de 0 , tandis que le débit atteint son maximum aux alentours de
- 840Mbit pour
-l8192, c'est-à-dire des paquets IP fragmentés - 250Mbit pour
-l1472les paquets IP non fragmentés
Je suppose que le contrôle de flux limite le débit et empêche la perte de paquets. Surtout ce dernier chiffre non fragmenté est loin du débit TCP (TCP non fragmenté donne des chiffres similaires à TCP fragmenté), mais c'est une amélioration infiniment énorme par rapport à Linux -> Windows en termes de perte de paquets.
Et comment le savoir?
J'ai suivi les conseils habituels pour les paramètres du pilote sur le serveur pour maximiser les performances et j'ai essayé d'activer / désactiver / maximiser / minimiser / modifier
- Interruption de la modération
- Contrôle de flux
- Tampons de réception
- RSS
- Wake-on-LAN
Toutes les fonctionnalités de déchargement sont activées.
Modifier j'ai également essayé d'activer / désactiver
- Ethernet @ Wirespeed
- Les différentes fonctionnalités de déchargement
- Priorité et VLAN
Avec des taux de perte similaires.
La sortie complète d'une exécution UDP:
$ iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:10:39 GMT
Connecting to host 192.168.30.161, port 5201
Cookie: mybox.1431522639.098587.3451f174
[ 4] local 192.168.30.202 port 50851 connected to 192.168.30.161 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 33.3 MBytes 279 Mbits/sec 4262
[ 4] 1.00-2.00 sec 35.8 MBytes 300 Mbits/sec 4577
[ 4] 2.00-3.00 sec 35.8 MBytes 300 Mbits/sec 4578
[ 4] 3.00-4.00 sec 35.8 MBytes 300 Mbits/sec 4578
[ 4] 4.00-5.00 sec 35.8 MBytes 300 Mbits/sec 4577
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-5.00 sec 176 MBytes 296 Mbits/sec 0.053 ms 3216/22571 (14%)
[ 4] Sent 22571 datagrams
CPU Utilization: local/sender 4.7% (0.4%u/4.3%s), remote/receiver 1.7% (0.8%u/0.9%s)
Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44770
[ 5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 50851
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.01 sec 27.2 MBytes 226 Mbits/sec 0.043 ms 781/4261 (18%)
[ 5] 1.01-2.01 sec 30.0 MBytes 252 Mbits/sec 0.058 ms 734/4577 (16%)
[ 5] 2.01-3.01 sec 29.0 MBytes 243 Mbits/sec 0.045 ms 870/4578 (19%)
[ 5] 3.01-4.01 sec 32.1 MBytes 269 Mbits/sec 0.037 ms 469/4579 (10%)
[ 5] 4.01-5.01 sec 32.9 MBytes 276 Mbits/sec 0.053 ms 362/4576 (7.9%)
Exécution TCP:
$ iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:13:53 GMT
Connecting to host 192.168.30.161, port 5201
Cookie: mybox.1431522833.505583.4078fcc1
TCP MSS: 1448 (default)
[ 4] local 192.168.30.202 port 44782 connected to 192.168.30.161 port 5201
Starting Test: protocol: TCP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 109 MBytes 910 Mbits/sec 0 91.9 KBytes
[ 4] 1.00-2.00 sec 97.3 MBytes 816 Mbits/sec 0 91.9 KBytes
[ 4] 2.00-3.00 sec 97.5 MBytes 818 Mbits/sec 0 91.9 KBytes
[ 4] 3.00-4.00 sec 98.0 MBytes 822 Mbits/sec 0 91.9 KBytes
[ 4] 4.00-5.00 sec 97.6 MBytes 819 Mbits/sec 0 91.9 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-5.00 sec 499 MBytes 837 Mbits/sec 0 sender
[ 4] 0.00-5.00 sec 498 MBytes 836 Mbits/sec receiver
CPU Utilization: local/sender 3.5% (0.5%u/3.0%s), remote/receiver 4.5% (2.0%u/2.5%s)
Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44781
[ 5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 44782
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 105 MBytes 878 Mbits/sec
[ 5] 1.00-2.00 sec 97.5 MBytes 818 Mbits/sec
[ 5] 2.00-3.00 sec 97.6 MBytes 819 Mbits/sec
[ 5] 3.00-4.00 sec 97.8 MBytes 820 Mbits/sec
[ 5] 4.00-5.00 sec 97.7 MBytes 820 Mbits/sec
la source
-lcommutateur. Il ne définit pas la taille du tampon; il définit la taille du paquet. Il s'agit de la quantité de données que iperf3 écrira sur le socket en une seule fois et lira sur le socket en une seule fois. Vous pouvez définir la taille du tampon de socket à l'aide de-w. Si vous regardez la source, vous verrez qu'elle appellesetsockopt()pour définir la taille du tampon de socket à ce que vous avez spécifié après-w.Vous avez complètement raté le coupable le plus évident - les adaptateurs, puis les pilotes (vous déclarez que l'utilisation d'une version différente des pilotes donne des résultats différents).
Essayez de désactiver toutes les capacités de déchargement.
la source