Linux tc流量整形不准确，带宽和延迟高

我正在使用内核2.6.38.8中的

tc

进行流量整形。限制带宽是可行的，增加延迟也是可行的，但是当使用延迟来塑造两个带宽时，如果限制大于1.5 Mbps左右，则实现的带宽总是远远低于限制

例如：

tc qdisc del dev usb0 root
tc qdisc add dev usb0 root handle 1: tbf rate 2Mbit burst 100kb latency 300ms
tc qdisc add dev usb0 parent 1:1 handle 10: netem limit 2000 delay 200ms

产生201毫秒的延迟（来自ping），但容量仅为1.66 Mbps（来自iperf）。如果我消除延迟，带宽正好是2Mbps。如果我指定1 Mbps的带宽和200 ms RTT，一切都可以正常工作。我还尝试了ipfw+dummynet，这会产生类似的结果

---

我曾尝试在Kconfig中使用

HZ=1000

重建内核，但没有解决问题。其他想法？

事实上这不是问题，它的行为应该是正常的。因为您增加了200毫秒的延迟，所以整个2Mbps管道没有充分发挥其潜力。我建议您更详细地研究TCP/IP协议，但这里有一个关于iperf的简短总结：您的默认窗口大小可能是3个数据包（每个数据包可能有1500字节）。您用3个数据包填充管道，但现在必须等待，直到您收到回执（这是拥塞控制机制的一部分）。由于发送延迟了200毫秒，这将需要一段时间。现在，您的窗口大小将增加一倍，接下来您可以发送6个数据包，但需要再次等待200毫秒。然后窗口大小再次翻倍，但当窗口完全打开时，默认的10秒iperf测试接近结束，您的平均带宽将明显变小。

这实际上不是问题，它的行为与它应该的一样。因为您增加了200毫秒的延迟，所以整个2Mbps管道没有充分发挥其潜力。我建议您更详细地研究TCP/IP协议，但这里有一个关于iperf的简短总结：您的默认窗口大小可能是3个数据包（每个数据包可能有1500字节）。您用3个数据包填充管道，但现在必须等待，直到您收到回执（这是拥塞控制机制的一部分）。由于发送延迟了200毫秒，这将需要一段时间。现在，您的窗口大小将增加一倍，接下来您可以发送6个数据包，但需要再次等待200毫秒。然后窗口大小再次翻倍，但当窗口完全打开时，默认的10秒iperf测试即将结束，您的平均带宽将明显变小。

这样想：

假设您将延迟设置为1小时，速度设置为2 Mbit/s

2 Mbit/s需要（例如）50 Kbit/s的TCP确认。由于ACK需要一个多小时才能到达源，因此源无法继续以2 Mbit/s的速度发送，因为TCP窗口仍在等待第一次确认

延迟和带宽的关系比你想象的要密切（至少在TCP中。UDP是另一回事）

这样想：

假设您将延迟设置为1小时，速度设置为2 Mbit/s

2 Mbit/s需要（例如）50 Kbit/s的TCP确认。由于ACK需要一个多小时才能到达源，因此源无法继续以2 Mbit/s的速度发送，因为TCP窗口仍在等待第一次确认

延迟和带宽的关系比你想象的要大（至少在TCP中是这样。UDP是另一回事）