Wifi TCP iperf吞吐量：1个流还是多个流？

12

在WLAN iperf TCP吞吐量测试中，多个并行流将为我提供比1个流更高的吞吐量。我尝试增加TCP窗口的大小，但仅1个流仍然无法达到最大吞吐量。TCP层中是否还有其他因素在阻止使用完整的链路容量？

wireless  ipv4  tcp  testing  iperf 
— elin05
source
您观察到多少差异？理想情况下，如果一个TCP流提供T的吞吐量，则两个TCP流应分别提供T / 2的吞吐量。
— Manoj Pandey
请注意，永远不会达到完整的链路容量，而不管流的数量如何。具有最少[IP + TCP]标头的IPv4将产生约95％的通道效率。参见sd.wareonearth.com/~phil/net/overhead上出色的协议开销发布。
— generalnetworkerror 2013年
@ManojPandey，我不确定他是否看到了理想的情况……尤其是因为他正在使用wifi ...我怀疑他有一些数据包丢失……
— Mike Pennington
TCP通过Wi-Fi进行处理。如果必须使用它，并且看到第3层数据包丢失，我建议增加第2层最大重试计数，因为TCP并非旨在处理有损链接而不破坏性能。
— BatchyX 2013年

Answers:

14

在WLAN iperf TCP吞吐量测试中，多个并行流将为我提供比1个流更高的吞吐量。我尝试增加TCP窗口的大小，但仅1个流仍然无法达到最大吞吐量。TCP层中是否还有其他因素在阻止使用完整的链路容量？

以我的经验，如果您看到1个TCP流和多个TCP流之间的结果明显不同，则问题通常是数据包丢失。因此TCP层中的“其他”是重传（由于较低层的数据包丢失）。

我整理了一个示例来说明数据包丢失如何影响单流吞吐量...

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

这是一张表格，总结iperf了客户端和服务器之间60秒测试的测试结果……您可能会发现RTPER抖动（即更高的RTT标准偏差）导致iperf结果略有变化；但是，最明显的区别是当我模拟2％的损失离开客户端有线NIC时出现的。172.16.1.56和172.16.1.80是同一台笔记本电脑（运行Ubuntu）。服务器为172.16.1.5，运行Debian。我在客户端有线NIC上使用netem来模拟数据包丢失...

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

编辑评论回复：

您能否解释一下最后一种情况（1000BaseT，5个流，2.0％的损失）发生了什么？即使有数据包丢失，总吞吐量仍然达到937 Mbits / sec。

当检测到数据包丢失时，大多数TCP实现都会减少其拥塞窗口。由于我们使用netem强制从客户端到服务器的2％数据包丢失，因此某些客户端数据被丢弃。netem在此示例中的净效果是730Mbps的单流平均传输速率。添加多个流意味着各个TCP流可以一起工作以使链接饱和。

我的目标是通过WiFi实现尽可能高的TCP吞吐量。据我了解，我应该增加流的数量，以应对由于数据包丢失而导致的吞吐量下降。它是否正确？

是

此外，过多的流将在什么时候开始对吞吐量产生负面影响？这是由有限的内存和/或处理能力引起的吗？

没有更多的实验，我无法真正回答这个问题，但是对于1GE链接，我从来没有遇到过将5个并行流饱和的问题。为了让您了解TCP的可扩展性，Linux服务器在适当的情况下可以处理1500个以上的并发TCP套接字。这是另一个与扩展并发TCP套接字有关的SO讨论，但是在我看来，如果您只是想使链接饱和，那么20个以上并行套接字的任何内容都将过大。

我一定会误解为iperf使用-w窗口大小作为最大值，这听起来像是您在说它的增长超出了21K的初始值

我没有使用过iperf -w，所以我认为存在误解。由于您对wifi案例有很多疑问，因此我为wifi单TCP流案例提供了TCP吞吐量的wireshark图。

Wifi TCP单流吞吐量

测试数据

我还包括原始测试数据，以防您想了解如何测量这些东西...

802.11g，1个TCP流

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流

[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个流，0.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                 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个流，0.0％损失

[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个流，2.0％损失

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个流，2.0％损失

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

删除丢包模拟

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc del dev eth0 root
— 迈克·彭宁顿
source
您能解释一下最后一种情况（1000BaseT，5个流，2.0％的损失）发生了什么吗？即使有数据包丢失，总吞吐量仍然达到937 Mbits / sec。我的目标是通过WiFi实现尽可能高的TCP吞吐量。据我了解，我应该增加流的数量，以应对由于数据包丢失而导致的吞吐量下降。它是否正确？此外，过多的流将在什么时候开始对吞吐量产生负面影响？这是由有限的内存和/或处理能力引起的吗？
— elin05 2013年
@ elin05：使用多个流会在多个流上分散丢包，因此，当发生丢包时，只有一个流会减小其TCP窗口的大小，而其他流则不受影响。
— BatchyX
802.11g（54Mbps）BDP是否不要求54KB的窗口大小以及8ms（16ms RTT / 2）的延迟，以使管道充满机上数据包？服务器端的窗口大小是多少？
— generalnetworkerror 2013年
@ generalnetworkerror，TCP窗口不是静态的...它们会根据TCP的需要而变化...在该捕获期间，Tsunami公告的最大窗口大小为1177600字节；海啸的平均窗口为1045083字节，在那60秒的测试中，平均RTT为32.2ms。
— Mike Pennington
@MikePennington：我一定会对iperf使用-w窗口大小作为最大值感到误解，因为这听起来像是您在说它的增长超过了21K的初始值。
— generalnetworkerror 2013年
2

这是单个tcp流的最大吞吐量的计算。

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

因此，您会遇到瓶颈，而延迟会发挥很大的作用。

— 詹姆斯·伯明翰
source
0

这可能是由于多个过程而不是一个过程。使用iperf 2.0.9，可以在客户端上通过-P 2进行测试。这将派生两个线程，而不是一个。大多数现代CPU具有多个内核，因此使用多个线程将能够利用它们。

— 麦克马洪
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.