来自发送方的 iperf3 udp 静默间隙
iperf3 udp silent gap from sending side
我使用 iperf3.7 来测量最大 4 Gbps 左右的系统的吞吐量。
iperf3 服务器 运行 正在 Linux 机器上。
我使用以下标志在客户端使用此命令启动流量，-R 选项让服务器发送到客户端：
iperf3 -c 32.0.161.84 -u -l 1360 -b 550M -P 8 -w 16M -R -t 3000
大多数时候一切都按预期工作，我收到大约 4 Gbps。
但在某些情况下，例如 10 次迭代中的 1-2 次，我收到的吞吐量低于预期。低多少似乎是随机的，可能是 2 Gbps 或 3 或 3.5。
当我遇到低吞吐量场景时，它通常会保持几分钟的低吞吐量。有时，几分钟后它可以自行恢复到最大速度，有时它会保持较低的时间。
当我遇到这种低吞吐量情况时，如果停止流量并重新开始，我可以获得良好的吞吐量情况，在这种情况下，客户端收到了一个新的 ip 地址，因为它在每次迭代中动态分配给客户端。
查看发送服务器端的打印输出，它说它正在发送 8x550M，我还检查了 ifstat，它也显示它发送 4400 Mbps。
仍在接收端接收较低的速度。
将iperf客户端（发送方）运行正在连接的机器的以太网卡镜像到wireshark中，显示不时有10.8毫秒的静默间隙，这可以解释接收到的较低速率.
wireshark capture
在这个使用 wireshark 的示例中，流量为 4.4 Gbps，然后突然之间，似乎是 10.8 毫秒的静默间隙，我们丢失了 4486 个 1360 字节的 ip 帧。
这可以解释为什么流量会暂时下降到 3 Gbps。
有人知道为什么会发生这种情况吗？这是否是可能在更高版本 3.8 或 3.9 中修复的已知问题？
任何额外的标志可能有助于避免这种情况？
我曾尝试 运行 另一台 Linux 机器上的服务器，但出现了同样的问题，所以我认为这不是机器本身的问题。
BR 尼克拉斯
我们将日志记录技术更改为一种叫做 net-sniff 的技术，然后当吞吐量较低时我们就再也看不到差距了。所以我最初提到的差距并不是真正的差距，更可能是日志记录中的错误。
因此我们认为 iperf3 可以正常工作，并认为较低的吞吐量是由于网络中的某些因素造成的。
我使用 iperf3.7 来测量最大 4 Gbps 左右的系统的吞吐量。
iperf3 服务器 运行 正在 Linux 机器上。 我使用以下标志在客户端使用此命令启动流量，-R 选项让服务器发送到客户端： iperf3 -c 32.0.161.84 -u -l 1360 -b 550M -P 8 -w 16M -R -t 3000
大多数时候一切都按预期工作，我收到大约 4 Gbps。 但在某些情况下，例如 10 次迭代中的 1-2 次，我收到的吞吐量低于预期。低多少似乎是随机的，可能是 2 Gbps 或 3 或 3.5。 当我遇到低吞吐量场景时，它通常会保持几分钟的低吞吐量。有时，几分钟后它可以自行恢复到最大速度，有时它会保持较低的时间。 当我遇到这种低吞吐量情况时，如果停止流量并重新开始，我可以获得良好的吞吐量情况，在这种情况下，客户端收到了一个新的 ip 地址，因为它在每次迭代中动态分配给客户端。
查看发送服务器端的打印输出，它说它正在发送 8x550M，我还检查了 ifstat，它也显示它发送 4400 Mbps。
仍在接收端接收较低的速度。
将iperf客户端（发送方）运行正在连接的机器的以太网卡镜像到wireshark中，显示不时有10.8毫秒的静默间隙，这可以解释接收到的较低速率.
wireshark capture
在这个使用 wireshark 的示例中，流量为 4.4 Gbps，然后突然之间，似乎是 10.8 毫秒的静默间隙，我们丢失了 4486 个 1360 字节的 ip 帧。 这可以解释为什么流量会暂时下降到 3 Gbps。
有人知道为什么会发生这种情况吗？这是否是可能在更高版本 3.8 或 3.9 中修复的已知问题？ 任何额外的标志可能有助于避免这种情况？ 我曾尝试 运行 另一台 Linux 机器上的服务器，但出现了同样的问题，所以我认为这不是机器本身的问题。
BR 尼克拉斯
我们将日志记录技术更改为一种叫做 net-sniff 的技术，然后当吞吐量较低时我们就再也看不到差距了。所以我最初提到的差距并不是真正的差距，更可能是日志记录中的错误。 因此我们认为 iperf3 可以正常工作，并认为较低的吞吐量是由于网络中的某些因素造成的。