丢包率与iperf和tcpdump

由于CPU无法跟上，我在UDP模式下经历了iPerf的重大数据丢失。 出于某种原因，使用UDP的iPerf似乎比使用TCP的iPerf更加占用CPU资源。 当您将iPerf设置为一半时，您会遇到同样的损失百分比吗？

要回答第二个问题：有多less数据包丢失是可以接受的，这取决于您正在运行的应用程序，您获得了多lessstream量。 真的，如果你的带宽限制不应该有任何损失。 对于大多数情况下，我可能不会抱怨太多的.25％，但如果你的速度非常高，那么这仍然是一个很大的损失。

[编辑1]我对这个主题有一些其他想法：

1. 尝试增加iPerf的速度。 如果在某个地方出现系统性问题，无论费率如何，您都可能会遇到相同的损失百分比。 如果你处于硬件的极限，或者你的提供商做了某种RED ，那么在某个特定的速度下可能不会有任何损失，然后在更高的损失上越来越差。
2. 做iPerf会话的tcpdump测量，只是为了validation你的testing是否准确。
3. 用TCP来尝试iPerf。 这不会报告损失，但如果您正在损失，那么连接将不能放大到非常高。 由于延迟也会影响到这一点，因此请确保以尽可能低的延迟对端点进行testing。
4. 根据连接内部的设备，确保尽可能靠近它。 例如，如果您的testing系统和边缘路由器之间有多个交换机，请移至直接连接的交换机。
5. 如果您有一台pipe理型交换机，请检查它上面的统计信息，以确保没有发生丢失。 我遇到了一些更便宜的交换机，当它们接近100Mbps的UDPstream量时，它们开始下降（尽pipe大部分是老式的和廉价的非托pipe交换机）。
6. 尝试将来自两个不同客户端的iPerfs同时连接到两个不同的主机，以确保限制不是CPU或便宜的本地NIC卡的结果。

那么，与TCP有机制来最大限度地利用一个stream，与UDP没有。 因此，每个应用程序都必须创build自己的机制，因此每个应用程序可能都使用不同的方法来完成。 Iperf可能会允许更多的数据包丢失，因为试图达到最大可用带宽而不关心信息是否被接收。 另一个应用程序可能会尝试不丢失很多数据包，并将数据包速率降低到连接中的可用吞吐量。

你使用tcpdump来检查使用iPerf确保你使用tcpdump计算出的数据包丢失与iperf匹配时的数据包丢失吗？

您可能会发现您的测量方法不具有可比性。

iperf是否会自动丢弃与UDP序列无关的数据包？ 您可能正在查看连接上的一点点抖动。