☰

300Mbit 时出现极端 UDP 数据包丢失（14%），但 TCP > 800Mbit 时不会重新传输

tag-icon • tag-icon performance tcp udp packetloss iperf
300Mbit 时出现极端 UDP 数据包丢失（14%），但 TCP > 800Mbit 时不会重新传输

我有一个用作客户端的 Linux 机器iperf3，测试了 2 个配备相同配置的 Windows 2012 R2 服务器机器，这些机器都带有 Broadcom BCM5721、1Gb 适配器（2 个端口，但只有 1 个用于测试）。所有机器都通过单个 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 数据包
  • 250Mbit -l1472，未分段的 IP 数据包

我猜流量控制会限制吞吐量，并防止数据包丢失。尤其是后者，未碎片化的数据远不及 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

答案1

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

数据包丢失的原因是 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

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

~$ 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 性能：在 ESnet 100G 测试平台上，在高 UDP 速率（超过 10Gbps）下，iperf3 出现了一些问题。症状是，在 iperf3 的任何特定运行中，接收器报告的丢失率约为 20%，无论客户端使用的 -b 选项是什么。此问题似乎不是 iperf3 特有的，可能是由于 iperf3 进程在 CPU 上的位置及其与入站 NIC 的关系。在某些情况下，可以通过适当使用 CPU 亲和性 (-A) 选项来缓解此问题。（问题 #55）

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

答案2

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

尝试关闭所有卸载功能。

相关内容