300Mbit（14％）处的UDP极端丢包，但不重传的TCP> 800Mbit

11

我有一个Linux盒子用作iperf3客户端，测试了2个配备Broadcom BCM5721、1Gb适配器（2个端口，但只有1个用于测试）的配置相同的Windows 2012 R2服务器盒。所有机器都通过一个1Gb交换机连接。

以例如300Mbit测试UDP

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

导致丢失所有已发送数据包的14％（对于具有完全相同硬件的其他服务器盒，但是使用较旧的NIC驱动程序，丢失大约为2％），即使丢失50Mbit也会发生丢失，尽管严重程度较低。使用等效设置的TCP性能：

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

产生800Mbit以北的传输速度，没有报告的重新传输。

始终使用以下选项启动服务器：

iperf3 -sB192.168.30.161

谁该怪？

  1. Linux客户端盒（硬件？驱动程序？设置？）？ 编辑：我只是将测试从一个Windows服务器盒运行到另一个，而300Mbit的UDP数据包丢失甚至更高，为22％
  2. Windows服务器框（硬件？驱动程序？设置？）？
  3. 连接所有测试机器的（单个）开关？
  4. 电缆？

编辑：

现在，我尝试了另一个方向：Windows-> Linux。结果：数据包丢失始终为0，而吞吐量最大达到大约

  • 840Mbit -l8192，即分段的IP数据包
  • 250MB，用于无碎片的-l1472IP数据包

我想流量控制会限制吞吐量，并防止数据包丢失。尤其是后者，无碎片的数据远不及TCP吞吐量（无碎片的TCP产生的数据与碎片TCP相似），但是在数据包丢失方面，它相对于Linux-> Windows而言是无限巨大的改进。

以及如何找出？

我确实遵循了服务器上驱动程序设置的常规建议以最大化性能，并尝试启用/禁用/最大化/最小化/更改

  • 中断适度
  • 流量控制
  • 接收缓冲区
  • 的RSS
  • 局域网唤醒

所有卸载功能均已启用。

编辑我也尝试启用/禁用

  • 以太网@线速
  • 各种卸载功能
  • 优先级和VLAN

损失率相近。

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运行：

$ 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 
— 尤金·别列索夫斯基
source

Answers:

8

没有问题。这是正常和预期的行为。

数据包丢失的原因是UDP没有任何拥塞控制。在tcp中，当拥塞控制算法开始时，它将告诉发送端减慢发送速度，以最大化吞吐量并最小化损耗。

因此，对于UDP，这实际上是完全正常的行为。如果接收队列过载，UDP不能保证传递，并且会丢弃数据包。如果您想要更高的UDP传输速率，则需要增加接收缓冲区。

-l或--len iperf选项应该可以解决问题。以及客户端上的目标带宽设置-b。

-l，--len n [KM]将读取/写入缓冲区的长度设置为n（默认8 KB）

8KB ?? 在没有拥塞控制的情况下，这有点不足。

例如在服务器端。

~$ iperf -l 1M -U -s

这就是我将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

但是对于使用默认设置的UDP我只能得到

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

经过一些试验，我发现必须同时设置长度和带宽目标。

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

服务器端：

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

用小缓冲区演示数据包丢失。老实说，这并不像我期望的那样极端。在Linux / Windows之间可以测试的iperf3的可靠来源在哪里？

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

服务器端：

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

您是否也查看过iperf3 github页面自述文件？

已知的问题

UDP性能：在高UDP速率（高于10Gbps）的ESnet 100G测试平台上使用iperf3注意到一些问题。症状是，在iperf3的任何特定运行中，接收方报告的丢失率均为20％左右，而与客户端上使用的-b选项无关。此问题似乎不是特定于iperf3的，并且可能是由于iperf3进程在CPU上的位置及其与入站NIC的关系引起的。在某些情况下，可以通过适当使用CPU亲缘关系（-A）选项来缓解此问题。（问题55）

您正在使用速度较慢的NIC，但我想知道它是否相关。

— 马特
source
是的，关于丢包，我将向您展示这是如何发生的。更新答案。
— 马特
谢谢马特，刚看到您的更新。我的iperf（在Windows服务器和Linux客户端上）都是2.0.5版。你的是啥呢？
— 尤金·别列索夫斯基
相同。实际上，当我将目标带宽设置为1G时，我得到的大带宽速率为14756449370562973696字节/秒，以及其他此类损坏的输出。所以我认为它可能坏了。我仍然认为问题出在缓冲区...我知道Windows在TCP和UDP缓冲方面做了一些不寻常的事情。
— 马特
奇怪。今天晚些时候，我可能会访问一个良好的10G生产环境，并在该环境中释放iperf3。让我们看看情况如何。
— 尤金·别列索夫斯基
1
我认为您误解了-l开关的作用。它没有设置缓冲区的大小。它设置包的大小。这是iperf3会一次性写入套接字并从套接字读取的数据量。您可以使用设置套接字缓冲区大小-w。如果您查看源代码，将会看到它调用setsockopt()将套接字缓冲区大小设置为在之后指定的大小-w。
— 安德拉斯·科恩
0

您完全错过了最明显的罪魁祸首-适配器，然后是驱动程序（您声明使用不同版本的驱动程序会产生不同的结果）。

尝试关闭所有卸载功能。

— 丹妮
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.