Perte de paquets UDP extrême à 300 Mbit (14%), mais TCP> 800 Mbit sans retransmission

11

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?

  1. 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%
  2. Les boîtiers du serveur Windows (matériel? Pilote? Paramètres?)?
  3. Le commutateur (unique) qui connecte toutes les machines de test?
  4. 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                  
Eugene Beresovsky
la source

Réponses:

8

Il n'y a pas de problème. Il s'agit d'un comportement normal et attendu.

La raison de la perte de paquets est qu'UDP n'a aucun contrôle de congestion. En tcp, lorsque les algorithmes de contrôle de congestion interviennent, il indique à l'extrémité de transmission de ralentir l'envoi afin de maximiser le débit et de minimiser les pertes.

C'est donc un comportement tout à fait normal pour UDP en fait. UDP ne garantit pas la livraison si la file d'attente de réception est surchargée et abandonnera les paquets. Si vous voulez des taux de transmission plus élevés pour UDP, vous devez augmenter votre tampon de réception.

L'option -l ou --len iperf devrait faire l'affaire. Et éventuellement le paramètre de bande passante cible -b sur le client.

-l, --len n [KM] définit la longueur du tampon de lecture / écriture sur n (8 Ko par défaut)

8 Ko ?? c'est un peu petit quand il n'y a pas de contrôle de congestion.

par exemple côté serveur.

~$ iperf -l 1M -U -s

C'est ce que j'obtiens Linux vers Linux

Client connecting to ostore, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 35399 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

Mais pour UDP en utilisant les paramètres par défaut, je ne reçois que

~$ iperf -u -c ostore 
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 52898 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.027 ms    0/  893 (0%)

WT?

Après quelques expériences, j'ai découvert que je devais définir à la fois la longueur et la cible de bande passante.

~$ iperf -u -c ostore -l 8192 -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 8192 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 60237 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec
[  3] Sent 146243 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

Du côté serveur:

~$ iperf -s -u -l 5M 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 5242880 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 36448
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.1 sec  1008 KBytes   819 Kbits/sec   0.018 ms    0/  126 (0%)
[  4] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 60237
[  4]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec   0.078 ms    0/146242 (0%)
[  4]  0.0-10.0 sec  1 datagrams received out-of-order

Pour démontrer la perte de paquets avec de petits tampons. Pour être honnête, ce n'est pas aussi extrême que je m'y attendais. Où est une source fiable pour iperf3 que je peux tester entre Linux / Windows?

~$ iperf -u -c ostore -l 1K -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1024 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 45061 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   674 MBytes   565 Mbits/sec
[  3] Sent 689777 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Du côté serveur:

~$ iperf -s -u -l 1K 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1024 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 45061
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Avez-vous également consulté le fichier lisez - moi de la page de github iperf3 ?

Problèmes connus

Performances UDP: certains problèmes ont été constatés avec iperf3 sur le banc d'essai ESnet 100G à des taux UDP élevés (supérieurs à 10 Gbit / s). Le symptôme est que, lors d'une exécution particulière d'iperf3, le récepteur signale un taux de perte d'environ 20%, quelle que soit l'option -b utilisée du côté client. Ce problème ne semble pas être spécifique à iperf3 et peut être dû au placement du processus iperf3 sur un processeur et à sa relation avec la carte réseau entrante. Dans certains cas, ce problème peut être atténué par une utilisation appropriée de l'option d'affinité CPU (-A). (Numéro 55)

Vous utilisez une carte réseau plus lente mais je me demande si elle est liée.

Mat
la source
Ouais et en ce qui concerne la perte de paquets, je vais vous montrer comment cela peut arriver. mise à jour de la réponse.
Matt
Merci Matt, viens de voir ta mise à jour. Mon iperf (sur le serveur Windows et le client Linux) est la version 2.0.5. Quel est ton?
Eugene Beresovsky
Le même. Et en fait, lorsque je règle la bande passante cible sur 1 G, j'obtiens des taux de bande passante bonkas de 14756449370562973696 octets / sec et d'autres sorties corrompues. Je pense donc que c'est probablement cassé. Je pense toujours que les problèmes sont des tampons ... Je sais que Windows fait des choses inhabituelles avec la mise en tampon TCP et UDP.
Matt
Étrange. Plus tard dans la journée, j'aurai probablement accès à un bon environnement de production 10G et je lâcherai iperf3 sur celui-ci. Voyons comment ça se passe.
Eugene Beresovsky
1
Je pense que vous comprenez mal ce que fait le -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 appelle setsockopt()pour définir la taille du tampon de socket à ce que vous avez spécifié après -w.
András Korn
0

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.

Dani_l
la source
Cela n'a pas aidé - question mise à jour en conséquence.
Eugene Beresovsky