Wifi TCP iperf Durchsatz: 1 Stream gegen mehrere Streams?

In einem WLAN-iperf-TCP-Durchsatztest erzielen mehrere parallele Streams einen höheren Durchsatz als ein Stream. Ich habe versucht, das TCP-Fenster zu vergrößern, kann aber immer noch nicht mit nur 1 Stream den maximalen Durchsatz erzielen. Gibt es noch etwas in der TCP-Schicht, das verhindert, dass die volle Verbindungskapazität genutzt wird?

— elin05
quelle

Wie viel Unterschied beobachten Sie? Wenn ein TCP-Stream einen Durchsatz von T bereitstellt, sollten idealerweise zwei einzeln einen Durchsatz von T / 2 bereitstellen.

— Manoj Pandey

Beachten Sie, dass die volle Verbindungskapazität unabhängig von der Anzahl der Streams niemals erreicht wird. IPv4 mit minimalen [IP + TCP] -Headern ergibt eine Kanaleffizienz von ~ 95%. Weitere Informationen finden Sie im hervorragenden Protokoll-Overhead-Posting unter sd.wareonearth.com/~phil/net/overhead .

— Generalnetworkerror

@ManojPandey, ich bin nicht sicher, ob er einen idealen Fall sieht ... vor allem, weil er WLAN verwendet ... Ich vermute, er hat einen Paketverlust ...

— Mike Pennington

TCP nervt über WLAN, damit umgehen. Wenn Sie es verwenden müssen und Sie Paketverluste der Schicht 3 sehen, würde ich vorschlagen, die maximale Wiederholungsanzahl der Schicht 2 zu erhöhen, da TCP nicht dafür ausgelegt ist, verlustbehaftete Verbindungen zu handhaben, ohne die Leistung zu beeinträchtigen.

— BatchyX

In einem WLAN-iperf-TCP-Durchsatztest erzielen mehrere parallele Streams einen höheren Durchsatz als ein Stream. Ich habe versucht, das TCP-Fenster zu vergrößern, kann aber immer noch nicht mit nur 1 Stream den maximalen Durchsatz erzielen. Gibt es noch etwas in der TCP-Schicht, das verhindert, dass die volle Verbindungskapazität genutzt wird?

Nach meiner Erfahrung liegt das Problem normalerweise beim Paketverlust, wenn Sie zwischen 1 TCP-Stream und mehreren TCP-Streams signifikant unterschiedliche Ergebnisse sehen. Das "andere" Element in der TCP-Schicht ist also die erneute Übertragung (aufgrund des Paketverlusts in der unteren Schicht).

Ein Beispiel, das ich zusammengestellt habe, um zu veranschaulichen, wie Paketverlust den Durchsatz eines einzelnen Streams beeinflusst ...

                   [Wifi||LAN-0.0%-Loss||LAN-2.0%-Loss]
+--------------+                                        +--------------+
|              |                                        |              |
| Thinkpad-T61 |----------------------------------------| Linux Server |
|              |                                        | Tsunami      |
+--------------+                                        +--------------+
iperf client             ------------------>            iperf server
                             Pushes data

Dies ist eine Tabelle, die die Testergebnisse eines 60-Sekunden- iperfTests zwischen einem Client und einem Server zusammenfasst. Es kann sein, dass die Iperf-Ergebnisse durch RTT-Jitter (dh höhere RTT-Standardabweichung) geringfügig abweichen. Der größte Unterschied ergab sich jedoch, als ich einen Verlust von 2% simulierte und die Client-Netzwerkkarte verdrahtete. 172.16.1.56 und 172.16.1.80 sind der gleiche Laptop (unter Ubuntu). Der Server ist 172.16.1.5 und läuft unter Debian. Ich habe netem auf dem Client-NIC verwendet, um den Paketverlust zu simulieren ...

Client IP       Transport    Loss     avg RTT    RTT StdDev    TCP Streams   Tput
-----------     ----------   ----     -------    ----------    -----------   ----------
172.16.1.56     802.11g      0.0%      0.016s          42.0              1     19.5Mbps
172.16.1.56     802.11g      0.0%      0.016s          42.0              5     20.5Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              1    937  Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              5    937  Mbps
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              1    730  Mbps <---
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              5    937  Mbps

BEARBEITEN für Kommentarantworten :

Können Sie erklären, was im letzten Szenario passiert (1000BaseT, 5 Streams, 2,0% Verlust)? Obwohl es zu Paketverlusten kommt, ist der Gesamtdurchsatz immer noch mit 937 Mbit / s gesättigt.

Die meisten TCP-Implementierungen verringern ihr Überlastungsfenster, wenn ein Paketverlust festgestellt wird. Da wir netem verwenden , um einen Paketverlust von 2% vom Client zum Server zu erzwingen, werden einige Daten des Clients gelöscht. Der Nettoeffekt von netem in diesem Beispiel ist eine durchschnittliche Übertragungsrate von 730 Mbit / s für einen Datenstrom. Durch das Hinzufügen mehrerer Streams können die einzelnen TCP-Streams zusammenarbeiten, um die Verbindung zu sättigen.

Mein Ziel ist es, den höchstmöglichen TCP-Durchsatz über WLAN zu erzielen. Soweit ich weiß, sollte ich die Anzahl der Streams erhöhen, um dem durch Paketverlust verursachten Durchsatzrückgang entgegenzuwirken. Ist das richtig?

Ab wann wirken sich außerdem zu viele Streams negativ auf den Durchsatz aus? Würde dies durch begrenzten Arbeitsspeicher und / oder Rechenleistung verursacht?

Ohne weitere Experimente kann ich das nicht wirklich beantworten, aber bei 1GE-Verbindungen hatte ich nie ein Problem damit, eine Verbindung mit 5 parallelen Strömen zu sättigen. Damit Sie einen Eindruck davon bekommen, wie skalierbar TCP ist, können Linux-Server unter den richtigen Umständen über 1500 gleichzeitige TCP-Sockets verarbeiten . Dies ist eine weitere SO-Diskussion , die für die Skalierung von gleichzeitigen TCP-Sockets relevant ist. Meiner Meinung nach wäre jedoch alles über 20 parallele Sockets zu viel des Guten, wenn Sie lediglich versuchen, eine Verbindung zu sättigen.

Ich muss ein Missverständnis haben, dass iperf die Fenstergröße -w als Maximum verwendet, da es sich so anhört, als ob Sie sagen, dass es über diesen 21-KB-Anfangswert hinaus gewachsen ist

Ich habe es nicht benutzt iperf -w, also denke ich, dass es ein Missverständnis gibt. Da Sie so viele Fragen zum WiFi-Fall haben, füge ich ein Wireshark-Diagramm des TCP-Durchsatzes für den WiFi-Fall eines einzelnen TCP-Streams hinzu.

Wifi TCP Single-Stream-Durchsatz

Testdaten

Ich füge auch rohe Testdaten hinzu, falls Sie sehen möchten, wie ich diese Dinge gemessen habe ...

802.11g, 1 TCP-Stream

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
  --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.8  16.0   0.7 189.4  42.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9000 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9000 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9000
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 40376 connected with 172.16.1.5 port 9000
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.1 sec   139 MBytes  19.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

802.11g, 5 TCP-Streams

[mpenning@tsunami]$ iperf -s -p 9001 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9001 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 37162 connected with 172.16.1.5 port 9001
[  5] local 172.16.1.56 port 37165 connected with 172.16.1.5 port 9001
[  7] local 172.16.1.56 port 37167 connected with 172.16.1.5 port 9001
[  4] local 172.16.1.56 port 37163 connected with 172.16.1.5 port 9001
[  6] local 172.16.1.56 port 37166 connected with 172.16.1.5 port 9001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  28.0 MBytes  3.91 Mbits/sec
[  5]  0.0-60.1 sec  28.8 MBytes  4.01 Mbits/sec
[  4]  0.0-60.3 sec  28.1 MBytes  3.91 Mbits/sec
[  6]  0.0-60.4 sec  34.0 MBytes  4.72 Mbits/sec
[  7]  0.0-61.0 sec  30.5 MBytes  4.20 Mbits/sec
[SUM]  0.0-61.0 sec   149 MBytes  20.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 Stream, 0,0% Verlust

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
>   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9002 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9002 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9002
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 49878 connected with 172.16.1.5 port 9002
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6.54 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 Streams, 0,0% Verlust

[mpenning@tsunami]$ iperf -s -p 9003 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9003 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9003
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 47047 connected with 172.16.1.5 port 9003
[  3] local 172.16.1.80 port 47043 connected with 172.16.1.5 port 9003
[  4] local 172.16.1.80 port 47044 connected with 172.16.1.5 port 9003
[  5] local 172.16.1.80 port 47045 connected with 172.16.1.5 port 9003
[  6] local 172.16.1.80 port 47046 connected with 172.16.1.5 port 9003
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  5]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  3]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[  7]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 Streams, 2,0% Verlust

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc add dev eth0 root netem corrupt 2.0%

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 1.7%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9004 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9004 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9004
TCP window size: 42.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 48910 connected with 172.16.1.5 port 9004
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-64.1 sec  5.45 GBytes   730 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 Streams, 2,0% Verlust

[mpenning@tsunami]$ iperf -s -p 9005 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9005 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9005
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 50616 connected with 172.16.1.5 port 9005
[  3] local 172.16.1.80 port 50613 connected with 172.16.1.5 port 9005
[  5] local 172.16.1.80 port 50614 connected with 172.16.1.5 port 9005
[  4] local 172.16.1.80 port 50612 connected with 172.16.1.5 port 9005
[  6] local 172.16.1.80 port 50615 connected with 172.16.1.5 port 9005
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  1.74 GBytes   250 Mbits/sec
[  7]  0.0-60.0 sec   711 MBytes  99.3 Mbits/sec
[  4]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.59 GBytes   228 Mbits/sec
[  5]  0.0-60.0 sec  1.24 GBytes   177 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

Entfernen Sie die Paketverlustsimulation

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc del dev eth0 root

— Mike Pennington
quelle

Können Sie erklären, was im letzten Szenario passiert (1000BaseT, 5 Streams, 2,0% Verlust)? Obwohl es zu Paketverlusten kommt, ist der Gesamtdurchsatz immer noch mit 937 Mbit / s gesättigt. Mein Ziel ist es, den höchstmöglichen TCP-Durchsatz über WLAN zu erzielen. Soweit ich weiß, sollte ich die Anzahl der Streams erhöhen, um dem durch Paketverlust verursachten Durchsatzrückgang entgegenzuwirken. Ist das richtig? Ab wann wirken sich außerdem zu viele Streams negativ auf den Durchsatz aus? Würde dies durch begrenzten Arbeitsspeicher und / oder Rechenleistung verursacht?

— Elin05

@ elin05: Wenn Sie mehrere Streams verwenden, wird der Paketverlust auf mehrere Streams verteilt. Wenn also ein Paketverlust auftritt, wird die Größe des TCP-Fensters nur von einem Stream verringert, die anderen Streams bleiben davon unberührt.

— BatchyX

Erfordert der 802.11g (54Mbps) BDP nicht eine Fenstergröße von 54 KB mit einer Verzögerung von 8 ms (16 ms RTT / 2), um die Pipe mit In-Flight-Paketen voll zu halten? Wie groß ist das Fenster auf der Serverseite?

— Generalnetworkerror

@generalnetworkerror, TCP-Fenster sind nicht statisch ... sie ändern sich basierend auf den Anforderungen von TCP ... während dieser Erfassung betrug die maximale Tsunami-Fenstergröße 1177600 Byte. Tsunamis durchschnittliches Fenster betrug 1045083 Bytes und die durchschnittliche RTT über diesen 60-Sekunden-Test betrug 32,2 ms.

— Mike Pennington

@MikePennington: Ich muss ein Missverständnis haben, dass iperf die Fenstergröße -w als Maximum verwendet, da es sich so anhört, als ob Sie sagen, dass sie über diesen 21-KB-Anfangswert hinaus gewachsen ist.

— Generalnetworkerror

Hier ist die Berechnung für den maximalen Durchsatz eines einzelnen TCP-Streams.

(TCP Window [bytes]/RTT[seconds]) * 8 [bits/byte] = Max single tcp throughput in (bps)

Sie haben also einen Engpass und die Latenz spielt eine große Rolle.

— James.Birmingham
quelle

Es liegt wahrscheinlich an mehreren Prozessen gegenüber einem Prozess. mit iperf 2.0.9 kann man dies über -P 2 auf dem client testen. Dies wird zwei Threads anstelle von einem gabeln. Die meisten modernen CPUs verfügen über mehrere Kerne, sodass sie bei Verwendung mehrerer Threads genutzt werden können.

— rjmcmahon
quelle