Extremer UDP-Paketverlust bei 300 Mbit (14%), aber TCP> 800 Mbit ohne erneute Übertragung

11

Ich habe eine Linux-Box, die ich als iperf3Client verwende und die 2 identisch ausgestattete Windows 2012 R2-Serverboxen mit Broadcom BCM5721, 1-GB-Adaptern (2 Ports, aber nur 1 für den Test verwendet) testet. Alle Maschinen sind über einen einzigen 1-Gbit-Switch verbunden.

Testen von UDP bei z. B. 300 Mbit

iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192

Dies führt zum Verlust von 14% aller gesendeten Pakete (für die andere Server-Box mit genau derselben Hardware, aber älteren NIC-Treibern beträgt der Verlust etwa 2%), aber der Verlust tritt auch bei 50 Mbit auf, wenn auch weniger schwerwiegend. TCP-Leistung mit entsprechenden Einstellungen:

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

liefert Übertragungsgeschwindigkeiten nördlich von 800 Mbit ohne gemeldete Neuübertragungen.

Der Server wird immer mit den folgenden Optionen gestartet:

iperf3 -sB192.168.30.161

Wer ist schuld?

  1. Die Linux-Client-Box (Hardware? Treiber? Einstellungen?)? Bearbeiten: Ich habe gerade den Test von einer Windows-Server-Box zur anderen ausgeführt und der UDP-Paketverlust bei 300 Mbit war mit 22% sogar noch höher.
  2. Die Windows Server Boxen (Hardware? Treiber? Einstellungen?)?
  3. Der (einzelne) Schalter, der alle Testmaschinen verbindet?
  4. Kabel?

Bearbeiten:

Jetzt habe ich die andere Richtung versucht: Windows -> Linux. Ergebnis: Paketverlust immer 0 , während der Durchsatz bei etwa maximal ist

  • 840 Mbit für -l8192, dh fragmentierte IP-Pakete
  • 250 Mbit für -l1472unfragmentierte IP-Pakete

Ich denke, die Flusskontrolle begrenzt den Durchsatz und verhindert Paketverlust. Insbesondere die letztere, unfragmentierte Zahl ist bei weitem nicht annähernd der TCP-Durchsatz (unfragmentierte TCP liefert ähnliche Zahlen wie fragmentiertes TCP), aber es ist eine unendlich große Verbesserung gegenüber Linux -> Windows in Bezug auf Paketverlust.

Und wie kann man das herausfinden?

Ich habe die üblichen Ratschläge für Treibereinstellungen auf dem Server befolgt, um die Leistung zu maximieren, und versucht, diese zu aktivieren / deaktivieren / maximieren / minimieren / ändern

  • Moderation unterbrechen
  • Ablaufsteuerung
  • Puffer erhalten
  • RSS
  • Wake on LAN

Alle Offload-Funktionen sind aktiviert.

Bearbeiten Ich habe auch versucht, zu aktivieren / deaktivieren

  • Ethernet @ Wirespeed
  • Die verschiedenen Offload-Funktionen
  • Priorität & VLAN

Mit ähnlichen Verlustraten.

Die vollständige Ausgabe eines UDP-Laufs:

$ 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-Lauf:

$ 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
performance  tcp  udp  packetloss  iperf 
— Eugene Beresovsky
quelle

Antworten:

8

Es gibt kein Problem. Dies ist normales und erwartetes Verhalten.

Der Grund für den Paketverlust ist, dass UDP keine Überlastungskontrolle hat. Wenn in tcp Algorithmen zur Überlastungskontrolle aktiviert werden, wird das Sendeende angewiesen, das Senden zu verlangsamen, um den Durchsatz zu maximieren und Verluste zu minimieren.

Dies ist also für UDP eigentlich ein ganz normales Verhalten. UDP garantiert keine Zustellung, wenn die Empfangswarteschlange überlastet ist und Pakete verwirft. Wenn Sie höhere Übertragungsraten für UDP wünschen, müssen Sie Ihren Empfangspuffer erhöhen.

Die Option -l oder --len iperf sollte den Trick machen. Und möglicherweise die Zielbandbreiteneinstellung -b auf dem Client.

-l, --len n [KM] Länge des Lese- / Schreibpuffers auf n setzen (Standard 8 KB)

8KB ?? Das ist ein bisschen klein, wenn es keine Überlastungskontrolle gibt.

zB auf der Serverseite.

~$ iperf -l 1M -U -s

Dies ist, was ich Linux zu Linux bekomme

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

Aber für UDP mit den Standardeinstellungen bekomme ich nur

~$ 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?

Nach einigen Experimenten stellte ich fest, dass ich sowohl die Länge als auch das Bandbreitenziel festlegen musste.

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

Serverseite:

~$ 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

Demonstration des Paketverlusts mit kleinen Puffern. Was ehrlich gesagt nicht so extrem ist, wie ich erwartet hatte. Wo ist eine zuverlässige Quelle für iperf3, gegen die ich zwischen Linux / Windows testen kann?

~$ 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

Serverseite:

~$ 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

Haben Sie sich auch die Readme-Seite der iperf3-Github-Seite angesehen ?

Bekannte Probleme

UDP-Leistung: Bei iperf3 auf dem ESnet 100G-Testbed wurden bei hohen UDP-Raten (über 10 Gbit / s) einige Probleme festgestellt. Das Symptom ist, dass der Empfänger bei einem bestimmten Lauf von iperf3 eine Verlustrate von etwa 20% meldet, unabhängig von der auf der Clientseite verwendeten Option -b. Dieses Problem scheint nicht iperf3-spezifisch zu sein und kann auf die Platzierung des iperf3-Prozesses auf einer CPU und seine Beziehung zur eingehenden Netzwerkkarte zurückzuführen sein. In einigen Fällen kann dieses Problem durch eine geeignete Verwendung der Option CPU-Affinität (-A) behoben werden. (Ausgabe Nr. 55)

Sie verwenden eine langsamere Netzwerkkarte, aber ich frage mich, ob dies verwandt ist.

— Matt
quelle
Ja, und was den Paketverlust betrifft, werde ich Ihnen zeigen, wie dies passieren kann. Antwort aktualisieren.
— Matt
Danke Matt, habe gerade dein Update gesehen. Mein iperf (sowohl auf dem Windows-Server als auch auf dem Linux-Client) ist Version 2.0.5. Welches ist deins?
— Eugene Beresovsky
Das Gleiche. Und tatsächlich, wenn ich die Zielbandbreite auf 1G einstelle, erhalte ich Bonkas-Bandbreitenraten von 14756449370562973696 Bytes / Sek. Und andere solche beschädigten Ausgaben. Also ich denke es ist wahrscheinlich kaputt. Trotzdem denke ich, dass die Probleme Puffer sind ... Ich weiß, dass Windows einige ungewöhnliche Dinge mit TCP- und UDP-Pufferung macht.
— Matt
Seltsam. Später heute werde ich wahrscheinlich Zugang zu einer guten 10G-Produktionsumgebung bekommen und iperf3 auf dieser loslassen. Mal sehen, wie das geht.
— Eugene Beresovsky
1
Ich denke, Sie verstehen falsch, was der -lSchalter tut. Die Puffergröße wird nicht festgelegt. es legt die Paketgröße fest. Dies ist die Datenmenge, die iperf3 auf einmal in den Socket schreibt und auf einmal aus dem Socket liest. Sie können die Socket-Puffergröße mit einstellen -w. Wenn Sie sich die Quelle ansehen, werden Sie feststellen, dass sie aufruft setsockopt(), um die Größe des Socket-Puffers auf die von Ihnen angegebenen Werte festzulegen -w.
— András Korn
0

Sie haben den offensichtlichsten Schuldigen völlig verpasst - die Adapter und dann die Treiber (Sie geben an, dass die Verwendung einer anderen Version der Treiber zu unterschiedlichen Ergebnissen führt).

Schalten Sie alle Offload-Funktionen aus.

— Dani_l
quelle
Das hat nicht geholfen - Frage entsprechend aktualisiert.
— Eugene Beresovsky
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.