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

评论

您观察到多少差异?理想情况下,如果一个TCP流提供的吞吐量为T,则两个TCP流应分别提供的吞吐量为T / 2。

请注意,无论流数量如何,都将永远无法达到完整的链接容量。具有最少[IP + TCP]标头的IPv4将产生约95%的通道效率。请参阅sd.wareonearth.com/~phil/net/overhead上出色的协议开销发布。

@ManojPandey,我不确定他是否看到了理想的情况……尤其是因为他正在使用wifi ...我怀疑他有一些数据包丢失...

TCP通过Wi-Fi进行处理。如果必须使用它,并且看到第3层数据包丢失,我建议增加第2层最大重试计数,因为TCP并非旨在处理有损链接而不破坏性能。

#1 楼


在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


此表总结了客户端和服务器之间60秒iperf测试的测试结果...您可能会发现RTPER抖动的iperf结果有些变化(即更高的RTT标准偏差);但是,最显着的区别是当我模拟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初始值。我认为有误会。由于您对wifi案例有很多疑问,因此我为wifi单个TCP流案例提供了TCP吞吐量的wireshark图。




测试数据

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

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


评论


您能否解释一下最后一种情况(1000BaseT,5个流,2.0%的损失)发生了什么?即使有数据包丢失,总吞吐量仍达到937 Mbits / sec。我的目标是通过WiFi实现最高的TCP吞吐量。据我了解,我应该增加流的数量,以应对由于数据包丢失而导致的吞吐量下降。这个对吗?此外,过多的流将在什么时候开始对吞吐量产生负面影响?这是由有限的内存和/或处理能力引起的吗?

–elin05
2013年9月17日在18:59

@ elin05:使用多个流将丢包分布在多个流上,因此,当发生丢包时,只有一个流将减小其TCP窗口的大小,而其他流则不受影响。

–BatchyX
2013年9月18日在7:17



802.11g(54Mbps)BDP是否不要求54KB的窗口大小以及8ms(16ms RTT / 2)的延迟,以使管道中充满机载数据包?服务器端的窗口大小是多少?

–generalnetworkerror
2013年9月18日在8:17



@ generalnetworkerror,TCP窗口不是静态的...它们会根据TCP的需要而变化...在该捕获期间,Tsunami公告的最大窗口大小为1177600字节;海啸的平均窗口为1045083字节,在那60秒的测试中,平均RTT为32.2ms。

–迈克·彭宁顿
13年9月18日在11:44

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

–generalnetworkerror
13年9月24日在7:46

#2 楼

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

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


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

#3 楼

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