0

我正在使用tc内核 2.6.38.8 进行流量整形。限制带宽有效，添加延迟有效，但是当使用延迟对带宽进行整形时，如果限制>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）。如果我消除延迟，带宽正好是 2 Mbps。如果我指定 1 Mbps 和 200 ms RTT 的带宽，一切正常。我也尝试过 ipfw + dummynet，它产生了类似的结果。

我已经尝试在 Kconfig 中使用重建内核HZ=1000——但这并没有解决问题。其他想法？

4

2 回答 2

6

这实际上不是问题，它的行为就像它应该的那样。因为您添加了 200 毫秒的延迟，所以完整的 2Mbps 管道并未发挥其全部潜力。我建议您更详细地研究 TCP/IP 协议，但这里是 iperf 发生情况的简短摘要：您的默认窗口大小可能是 3 个数据包（每个可能 1500 字节）。你用 3 个数据包填充你的管道，但现在必须等到你得到一个确认（这是拥塞控制机制的一部分）。由于您将发送延迟 200 毫秒，这将需要一段时间。现在您的窗口大小将增加一倍，接下来您可以发送 6 个数据包，但再次需要等待 200 毫秒。然后窗口大小再次翻倍，但当你的窗口完全打开时，

于 2012-11-11T16:30:45.103 回答
0

可以这样想：

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

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

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

于 2015-08-18T17:05:32.290 回答