☰

Linux 流量控制严重滞后 - TBF 失败？

tag-icon • tag-icon ubuntu-18.04 tc traffic-shaping
Linux 流量控制严重滞后 - TBF 失败？

我一直在使用 Ubuntu18.04，并尝试使用 linux tc 来调整流量。过去几个月一切进展顺利。以下是我的命令：

# init queue
sudo tc qdisc add dev enp2s0 root handle 1:0 tbf rate 20mbit limit 16k burst 10k
sudo tc qdisc add dev enp2s0 parent 1:0 handle 10: netem rate 20mbit

# continuously adjust the traffic using following command with python
sudo tc qdisc add dev enp2s0 parent 1:0 handle 10: netem rate <bandwidth>kbit delay <rtt>ms loss <loss>%

然而最近几天我注意到 TBF 似乎停止工作了。

我怎么知道

我使用iperf3来测试链接：

# receiver, a windows pc
iperf3 -s

# sender, a linux PC performing tc & iperf client
iperf3 -u -c <receiver's ip> -b 1.5M -t 1000

带宽设置为1兆位/秒。

  1. 我观察到巨大的滞后发送方设置的带宽波动与接收方观察到的吞吐量之间的差异。
  2. 发送者退出后，接收者几秒钟后仍可​​收到剩余的数据包. (总计约5~10 Mbit)
  3. 当我尝试使用 iperf 时，一切正常TCP: iperf3 -c <receiver's ip> -b 1.5M -t 1000。我认为这是因为 TCP 有一个方案来限制带宽，不会产生过多的数据包。这就是为什么我认为是 TBF 而不是其他组件失败了。

我试过了

  1. 更换网卡
  2. 更改 iperf 客户端
  3. 更换电缆

以上都无济于事。

答案1

嗯，iperfUDP 模式下的客户端以您用标志配置的速率发送数据-b，在您的例子中是 1.5mbps。如果您将其设置为 10mbps，它将以该速度发送并报告。在这种情况下，实际获得的带宽在服务器端（即接收方）报告，因为客户端无法通过 UDP 获取它。

排队规则tbf是经典的令牌桶。简而言之，它将以配置的速率传递流量，并缓冲超出的部分，直到缓冲区溢出。拥塞消除后，缓冲的流量将按接收顺序传送，是的，如果您以千比特为单位配置速率，它将被显著延迟。

因此，如果您将几兆位转储到设置为小得多的整形器中，那么您看到的结果实际上是可以预期的 - 发送方（客户端）将仅以设置的速率转储数据-b并离开建筑物；TBF 将传递允许的内容并缓冲其余内容，由于缓冲区溢出，一些数据将丢失；由于缓冲过多，接收器将延迟接收数据。使用 UDP，您应该查看接收器端的统计数据，而不是发送方端的统计数据。

相关内容