☰

iperf 给出不正确的结果

tag-icon • tag-icon networking performance iperf
iperf 给出不正确的结果

我刚刚安装了新的宽带，想用 iperf3 测试它的吞吐量。但是它给出的结果似乎与更传统的速度测试有很大不同。

E:\tmp> iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.01  sec  13.1 MBytes  11.0 Mbits/sec                  sender
[  4]   0.00-10.01  sec  13.1 MBytes  11.0 Mbits/sec                  receiver

而在线速度测试显示预期结果约为 150 Mbits

3.testdebit.info 已从 azure 进行测试，并且始终保持在 330Mbits 左右（虽然谁知道这意味着什么！）

我尝试过各种不同的服务器，包括托管在 Azure 上的 Linux 机器 - 它向另一个 Azure 机器提供约 100Mbits 的带宽。这也在端口 80 上执行，以排除任何 ISP 限制。所有这些结果都是可比较的。

下载一个 3.5GB 的文件需要 210 秒，大约需要 130Mbit

有人可以解释一下为什么 iperf3 会这么低吗（或者我真的很笨并且读错了！）

这些都在同一台计算机上，通过以太网，因此不会受到无线等干扰。

编辑以添加

使用 iperf2 执行相同的测试（在 Windows 客户端（iPerf 2.0.5-3）和 ubuntu（iperf 版本 2.0.5）上）得到以下结果

E:\tmp\iperf2> iperf -c <hidden>.cloudapp.net -p 5201
------------------------------------------------------------
Client connecting to <hidden>.cloudapp.net, TCP port 5201
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 51816 connected with <hidden> port 5201
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  12.1 MBytes  10.0 Mbits/sec

从基于 Linux 的 NAS 执行相同的操作

Nas:~# iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  14.5 MBytes  12.2 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  14.5 MBytes  12.2 Mbits/sec                  receiver

使用 -R 标志

E:\tmp> iperf3 -c 3.testdebit.info -R
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  58.0 MBytes  48.6 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  57.0 MBytes  47.8 Mbits/sec                  receiver

为了确保这不是服务器问题，我已将 Azure VM 升级到可以从 3.testdebit.info 服务器拉取 600Mbit 上行 / 1Gbit 下行的大小

回应 John Looker 的回答

我提出这个问题的主要目的是试图理解为什么 iperf 给出的结果如此不同。我知道上传被大量共享，我对此并不太关心（或者至少这是一个不同的问题！）

我使用的 Azure 服务器位于北欧和西欧（我记得是阿姆斯特丹和爱尔兰），在线速度测试结果达到 240Mb/s

然而，问题似乎是多线程，我刚刚重新运行了测试，使用四个线程而不是默认线程 -

E:\tmp>iperf3 -c 3.testdebit.info -R -P 5
Connecting to host 3.testdebit.info, port 5201
Reverse mode, remote host 3.testdebit.info is sending
- - - - - - - - - - - - - - - - - - - - - - - - -
[SUM]   0.00-10.00  sec   195 MBytes   163 Mbits/sec   50             sender
[SUM]   0.00-10.00  sec   190 MBytes   160 Mbits/sec                  receiver

答案1

  1. 良好的传统速度测试是多线程的，并会与速度测试服务器建立多个连接。从而最大限度地发挥您的连接的潜力。

http://www.thinkbroadband.com/faq/sections/flash-speed-test.html#324

  1. iPerf3 似乎仅创建两个连接（使用默认选项），这可能不足以最大化您的 152Mb 宽带，特别是在出现拥塞时。

  2. 您的下载测试还表明有多线程连接。

下载一个 3.5GB 的文件需要 210 秒，大约需要 130Mbit

但你的计算是错误的。

((3.5GB x 8bits x1024x1024x1024)/210s)/1000000Mbit = 平均143Mb/s。

143Mb/s 的平均速度对于 152Mb 层的下载来说已经很不错了。

虽然 152Mb 层的最大突发下载速度为 161Mb/s（您的调制解调器配置过高以保证速度），但由于多种因素，平均速度通常会略低。

  • 服务器进行速率限制。
  • TCP 接收窗口需要时间来提高速度。
  • 电缆调制解调器请求-授予周期。
  • 节点拥塞。您正在与数百人共享您的有线连接（因此也共享您的下行信道）。您在有线调制解调器上锁定的 8 x 256 QAM 下行信道的最大可用带宽为 400Mb，来自节点。此带宽由您和您有线上与您使用相同信道的所有其他用户共享。当其他用户在您下载期间使用他们的连接时，速度自然会略有不同。
  • 路线拥堵。
  • 服务器拥塞。
  • 任何数据包丢失和重新传输。

上行带宽与您到节点的电缆上的其他用户竞争激烈。

如果您锁定了 2 x 16 QAM 上行信道，那么您将与许多其他用户共享 2 x 17Mb = 34Mb。如果您锁定了 2 x 64 QAM 上行信道，那么您将与许多其他用户共享 2 x 27Mb = 54Mb。

  1. 长距离传输时，延迟将成为影响传输速度的一个因素。

您没有说明您使用的是哪个 Azure 服务器，是英国、欧洲还是美国。

您的 iPerf3 服务器位于法国，可能会也可能不会通过 LINX 路由，具体取决于您的位置。一旦离开 VM 网络，路由拥塞有时可能会成为问题，尤其是在对等点。

  1. 非标准端口通常会被视为 P2P 流量。 http://www.thinkbroadband.com/faq/sections/flash-speed-test.html#323

虽然在 30Mb 及以上的层级上下载、流媒体、游戏等没有下行流量管理，但如果您的流量被归类为 P2P，那么它将受到流量管理并且在高峰时段降低速度。

原因是上行带宽非常稀缺，因为它由数百名用户共享，因此任何可能淹没上行的程序都会对电缆上的每个人都非常不利。这也是为什么上行仍然受到流量管理的原因。

在高峰时段之外，您可以按照自己喜欢的任何方式最大限度地利用您的连接。

  1. 小心使用小文件大小的测试。这里有一系列的测试文件可供您使用：http://www.thinkbroadband.com/download/

  2. 您的下载不太可能由 CDN 提供或缓存在 VM 网络内。当我使用 152Mb 时，我经常直接从服务器下载并以 161Mb 的速度流式传输。CDN 往往会使传输速度变慢而不是变快！

您需要提供有关测试策略的更多细节以回答原始问题。

答案2

请注意，IPerf 默认为“上传”测试：IPerf 客户端（-c）发送TCP 数据到 IPerf 服务器（-s）。看起来您正在 LAN 上运行客户端并连接到托管在公共 Internet 上的 IPerf 服务器，因此您正在测试新宽带连接的上传速度，而不是下载速度。

-s要测试其下载速度，请反转您以/调用的那一端-c，或使用-r指定您希望它在进行正常测试后执行“反向”（下载）测试。

请注意，如果您的 LAN 机器位于 NAT 或防火墙后面，您可能必须适当地打开/映射/转发端口才能进行下载测试。

相关内容