linux - 为什么我的基于 Linux prio 的 tc 没有改善网络延迟？

Question

我正在构建一个具有各种网络流量的实时嵌入式 Linux 应用程序。在这组流量中，有两个连接是时间关键的。一个是输入数据，另一个是输出数据。我的应用程序需要此流量优先于其他非时间关键流量。

我关心两件事:

1. 尽量减少因这两个连接过载而导致的丢包数。
2. 最大限度地减少设备(输入到输出)在这两个连接上的延迟。

我已经(有点!)加快了 Linux 流量控制的速度，并且了解到它主要适用于导出流量，因为远程设备负责它发送给我的数据的优先级。我已将我的应用程序设置为实时进程，并解决了与运行它的优先级相关的问题。

我现在开始设置 tc。对于我的测试用例，这是我使用的:

tc qdisc add dev eth0 root handle 1: prio bands 3 priomap 2 2 2 2 2 2 2 0 2 2 2 2 2 2 2 2
tc qdisc add dev eth0 parent 1:1 handle 10: pfifo
tc qdisc add dev eth0 parent 1:2 handle 20: pfifo
tc qdisc add dev eth0 parent 1:3 handle 30: pfifo

基本上我是说:通过频段 0 发送所有优先级为 7 的流量，并通过频段 2 发送所有其他流量。一旦我进行了这个简单的测试，我就会更好地处理其他流量。

首先让我们验证一下我的期望:我期望的是任何具有优先级 7 的流量应该总是在具有 任何 其他优先级的流量之前出去。这应该使此类流量的延迟相对不受盒子上其他流量的影响，不是吗？我的 mtu 设置为 1500，我通过界面获得大约 10 MB/秒的速度。频带 2 流量导致的频带 0 上的最大额外延迟是一个数据包(<=1500 字节)或 150 微秒(1500 字节/10 兆字节/秒 = 150 微秒)。

这是我的测试设置:

两个 Linux 盒子。框 1 运行一个 TCP 服务器来回显输入数据。盒子 2 连接到盒子 1，通过 TCP 发送数据包并测量延迟(发送时间到接收时间)。

我对 box Linux boxes 使用相同的 tc 设置。

在应用程序(服务器和客户端)中，我在套接字上设置 SO_PRIORITY 如下:

int so_priority = 7;
setsockopt(m_socket.native(), SOL_SOCKET, SO_PRIORITY, &so_priority, sizeof(so_priority));

我使用 tc 来验证我的流量是否通过 band 0，以及所有其他流量是否通过 band 2:

tc -s qdisc ls dev eth0

问题在于:当没有其他流量时，我发现延迟在 500 微秒左右。当我有其他流量时(例如，复制 100 MB 文件的 scp 作业)，延迟会上升到 10+ ms。真正奇怪的是，我所做的 tc 工作没有任何影响。事实上，如果我交换频段(因此我的所有流量都通过优先级较低的频段 2，而其他流量通过频段 1)，我看不到延迟有任何差异。

我的预期是，当网络上有其他流量时，我会看到延迟增加了大约 150 微秒，而不是 10 毫秒!顺便说一下，我已经验证用其他(非实时优先级)进程加载盒子不会影响延迟，也不会影响其他接口(interface)上的流量。

另一项注意事项是，如果我将 mtu 降低到 500 字节，则延迟会降低到大约 5 毫秒。尽管如此，这仍然比未加载的情况差一个数量级。还有--为什么改mtu影响这么大，而用tc设置优先级队列却没有效果？？？

为什么 tc 不帮助我？我错过了什么？

谢谢!

埃里克

Answer 1

您没有说您网络的其余部分，但我猜您正在上游路由器处排队，通常有很长的队列来优化吞吐量。解决它的最佳方法是将您的优先级队列馈送到带宽刚好低于上行带宽的整形器中。这样，您的批量优先级数据包将在您的盒子内排队，而不是在外部路由器处排队，从而允许您的高优先级数据包按您的预期跳到队列的前面。