Perte de paquets UDP extrême à 300MBIT (14%), mais TCP> 800MBIT W / O retransmits

Question

J'ai une boîte Linux que j'utilise comme iperf3 Client, Test 2 Boîtes de serveur Windows 2012 équipées de Windows 2012 avec Broadcom BCM5721, 1 Go d'adaptateurs (2 ports, mais seulement 1 utilisé pour le test). Toutes les machines sont connectées via un seul commutateur de 1 Go.

Test UDP à par ex. 300 mbit

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îte de serveur avec exactement le même matériel, mais plus ancien NIC pilotes, perte est d'environ 2%), mais la perte se produit même à 50MBIT, Bien que moins sévèrement. TCP Performances en utilisant des paramètres équivalents:

iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192

donne des vitesses de transmission au nord de 800MBIT, sans retransmissions rapporté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?)?~~ Modifier : Je viens de courir le test à partir d'une boîte de serveur Windows à l'autre et la perte de paquets UDP à 300BIT était encore plus élevée, à 22%
Les boîtes de serveur Windows (matériel? Pilote? Paramètres?)?
Le commutateur (unique) qui connecte toutes les machines à tester?
Câbles?

Edit :

Maintenant j'ai essayé l'autre direction: Windows -> Linux. Résultat: perte de paquets toujours, tandis que le débit maxe autour de

840MBIT pour -l8192, c'est-à-dire des paquets IP fragmentés
250mbit pour -l1472, paquets IP non fragmentés

Je suppose que le débit des bouchons de contrôle de flux et empêche la perte de paquets. Surtout ce dernier, la figure non fragmentée n'est nulle part près TCP Débit (nonFRAGMENTED TCP donne des chiffres similaires au TCP fragmenté), mais c'est une amélioration infiniment énorme sur Linux -> Windows en termes de perte de paquets.

et comment savoir?

J'ai suivi les conseils habituels des paramètres de pilotes sur le serveur afin de maximiser les performances et essayé d'activer/désactiver/maximiser/minimiser/modifier

Modération d'interruption
Contrôle de flux
Tampons de réception
RSS
Wake-on-lan

~~Toutes les fonctionnalités de déchargement sont activées.~~

éditer J'ai également essayé d'activer/désactiver

Ethernet @ WireSeed
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%)

TCP Run:

$ 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

Matt · Answer

Il n'y a pas de problème. C'est un comportement normal et attendu.

La raison de la perte de paquets est que UDP n'a pas de contrôle de congestion. Dans TCP lorsque les algorithmes de contrôle de la congestion lancent, il indiquera à la fin de transmission de ralentir l'envoi afin de maximiser le débit et de minimiser la perte.

C'est donc un comportement entièrement normal pour UDP en fait. UDP ne garantit pas la livraison si la file d'attente de réception est surchargée et supprimera des paquets. Si vous souhaitez des tarifs de transmission plus élevés pour UDP, vous devez augmenter votre mémoire 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éfinir la longueur de la longueur de lecture/écriture tampon à n (8 KB par défaut)

8kb ?? C'est un peu du petit côté quand il n'y a pas de contrôle de congestion.

par exemple. du côté serveur.

~$ iperf -l 1M -U -s

C'est ce que je reçois Linux à 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 utilisant les paramètres par défaut, je reçois seulement

~$ 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 une certaine expérimentation, j'ai trouvé que je devais mettre à 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. Ce qui est honnête n'est pas aussi extrême que je m'attendais. Où est une source fiable pour iperf3, 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 examiné la page IPERF3 GITUB Page README?

Problèmes connus

Performances UDP: Certains problèmes ont été remarqués avec IPERF3 sur le banc d'essai ESNET 100G à des taux élevés UDP (supérieurs à 10 Gbps). Le symptôme est que sur toute course particulière de IPERF3, le récepteur rapporte un taux de perte d'environ 20%, quelle que soit l'option -b utilisée du côté du client. Ce problème ne semble pas être spécifique à IPERF3 et peut être dû à la mise en place du processus IPERF3 sur une CPU 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 Affinity CPU (-A). (Numéro 55)

Vous utilisez un fichier plus lent NIC mais je me demande si c'est lié.

Dani_l · Answer

Vous avez complètement manqué le coupable le plus évident - les adaptateurs, puis les pilotes (vous indiquez que l'utilisation d'une version différente conductrice donne différents résultats).

Essayez de désactiver toutes les capacités de déchargement.