服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 在300Mbit（14％）的极端UDP数据包丢失，但TCP> 800Mbit w / o重新传输
Intereting Posts
使用SSL缓慢重新启动Apache2 我可以在一个系统中安装两个稍微不同的CPU吗？ 通过RDP打印机redirect打印时，Windows 10 RDP客户端崩溃 NFS自动挂载挂起 页面分配失败 – 我内存不足？ apache2：获取已注册的处理程序列表 Coldfusion服务器监控：选项和意见 停止某些用户访问安全组的C：\ Source OpenVPN权限被拒绝错误 用独立IP桥接VirtualBox虚拟机 如何保护Mac服务器（日志中的“可能的破解尝试”） Windows 7，networking共享和本地组身份validation，而不是本地用户 有没有办法通过caching而不是通过克隆来部署Opsworks？ 仍然值得防火墙/过滤ssh访问，除了特定的IP？ 与ASA的Strongswan RA和Strongswan站点2站点

在300Mbit（14％）的极端UDP数据包丢失，但TCP> 800Mbit w / o重新传输

我有一个我用作iperf3客户端的linux系统，testing了2个与Broadcom BCM5721，1Gb适配器（2个端口，但只有1个用于testing）相同的Windows 2012 R2服务器盒。 所有机器都通过一个1Gb交换机连接。

在例如300MbittestingUDP 

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

导致所有数据包丢失的14％（对于硬件完全相同的其他服务器机箱，但较旧的NIC驱动程序，损失大约为2％），但即使在50Mbit的时候也会出现丢失，尽pipe不太严重。 使用等效设置的TCP性能： 

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

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

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

 iperf3 -sB192.168.30.161

谁应该责怪？

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

编辑：

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

  • 840Mbit为-l8192 ，即分段的IP数据包
  • 250Mbit为-l1472 ，未分片的IP数据包

我想stream量控制上限吞吐量，并防止数据包丢失。 特别是后者，没有碎片的数字远远没有达到TCP吞吐量（不分片的TCP产生与碎片化的TCP类似的数字），但是在数据包丢失方面，它比Linux – > Windows有了无限的巨大改进。

以及如何找出？

我确实按照服务器上的驱动程序设置的通常build议来最大限度地提高性能，并尝试启用/禁用/最大化/最小化/更改

  • 中断审核
  • stream量控制
  • 接收缓冲区
  • RSS
  • networking唤醒

所有卸载function都已启用。

编辑我也尝试启用/禁用

  • 以太网线速@
  • 各种卸载function
  • 优先级和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

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

丢包的原因是UDP没有任何拥塞控制。 在拥塞控制algorithm启动时，tcp会告诉发送端放慢发送速度，以最大限度地提高吞吐量并减less丢包。

所以这对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之间进行testing？ 

 ~$ 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 100Gtesting平台上的iperf3在UDP速率较高（10Gbps以上）时，会出现一些问题。 其症状是在任何特定的iperf3运行中，无论客户端使用-b选项，接收器都会报告大约20％的丢失率。 此问题似乎不是iperf3特定的，可能是由于在CPU上放置了iperf3进程及其与入站NIC的关系。 在某些情况下，通过适当使用CPU关联（-A）选项可以缓解此问题。 （问题＃55）

你正在使用较慢的网卡，但是我想知道它是否相关。

你完全错过了最明显的罪魁祸首 – 适配器，然后司机（你说使用不同的版本驱动程序产生不同的结果）。

尝试closures所有卸载function。