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

【问题标题】：Why is my Linux prio based tc not improving network latency?为什么我的基于 Linux prio 的 tc 没有改善网络延迟？
【发布时间】：2011-04-14 22:47:58
【问题描述】：

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

我关心两件事：

尽量减少由于这两个连接过载而丢弃的数据包数量。
通过设备（输入到输出）在这两个连接上的延迟最小化。

我已经（有点！）了解 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

基本上我的意思是：发送所有优先级为 7 的流量通过频段 0，所有其他流量通过频段 2。一旦我完成了这个简单的测试，我会更好地处理其他流量。

首先让我们验证一下我的期望：我期望的是，任何具有优先级 7 的流量都应始终在具有任何其他优先级的流量之前发出。这应该使此类流量的延迟相对不受盒子上其他流量的影响，不是吗？我的 mtu 设置为 1500，我通过界面获得了大约 10 MB/秒的速度。由频段 2 流量引起的频段 0 上的最大额外延迟是一个数据包（

这是我的测试设置：

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

我对盒式 Linux 盒使用相同的 tc 设置。

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

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

我使用 tc 来验证我的流量是否超过频段 0，以及所有其他流量是否超过频段 2：

tc -s qdisc ls dev eth0

问题来了：当没有其他流量时，我发现延迟在 500 us 范围内。当我有其他流量（例如，复制 100 MB 文件的 scp 作业）时，延迟会上升到 10+ 毫秒。真正奇怪的是，我所做的所有 tc 工作都没有任何影响。事实上，如果我交换频段（因此我的所有流量都通过较低优先级的频段 2，而其他流量通过频段 1），我看不出延迟有任何差异。

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

还有一点需要注意的是，如果我将 mtu 降低到 500 字节，延迟会降低到大约 5 毫秒。尽管如此，这比空载情况下要差一个数量级。还有--为什么改mtu对它影响这么大，但是用tc设置优先队列却没有效果？？？

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

谢谢！

埃里克

【问题讨论】：

据我所知，基于 prio 的 tc 提高了带宽，而不是延迟。
Mike - 这与文档不符。如果你“man prio”，它会说“在不需要减慢流量时降低延迟非常有用。”这正是我正在寻找的。span>

标签： linux networking tcp ip qos

【解决方案1】：

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

【讨论】：

听起来不错。所以，我移除了两个盒子之间的所有开关（以太网端口支持自动交叉），然后重新运行测试——结果相同。这可能与使用 TCP 有关吗？
不。使用 UDP 重新运行并看到同样的问题。啊！！
嗯。也许可以从手册页的错误部分尝试这个建议：较低频段的大量流量会导致较高频段的饥饿。可以通过将整形器（例如，tc-tbf(8) 附加到这些频带以确保它们不能支配链接来防止它们。
刚刚有了另一个想法。如果您的批量流量与您的交互式流量流向同一主机，则它可能会在入口排队。我不太了解入口端，但也许尝试在该端设置相同的优先级队列？
这是错误部分中的一个很好的（不是）评论。似乎是一个明显的错误。我设置了一个令牌桶来限制流量。这肯定有帮助（延迟降至最大约 8 毫秒），但绝对没有解决问题。

【解决方案2】：

prio 工具只会发送它发送数据包时可用的最高优先级数据包（通常在发送前一个数据包后立即发送，除非没有数据包等待发送）。

您的测试依赖于每台机器上的适当程序进程已将数据包放入队列中，以及已从每台机器上的端口检索接收到的数据包。

任何影响进程在任一计算机上的时间的调度延迟都可能影响进程将消息放入队列或从队列检索和处理消息的能力。听起来您至少已经加载了一台机器来测试这一点，但我的经验是，机器加载肯定会影响这样的测量延迟（以毫秒而不是微秒为单位），因此可能值得在两台机器加载的情况下重复此操作具有高优先级的任务。

要检查的另一件事是您用来测量延迟的时间戳——它是在客户端机器上实际接收到回显消息的时间，还是您的程序处理它的时间。如果是后者，那么您不仅要测量网络延迟，还要测量从收到消息到您的程序获得处理器片并到达您检查时间点之间的时间 - 请参阅http://wiki.wireshark.org/Timestamps。

顺便说一句，如果没有类似实时操作系统的机制，我认为您将无法获得有保证的微秒级响应能力。另一方面，如果您的应用程序是 VoIP 之类的，那么您通常可以接受大约 200 毫秒的延迟。

【讨论】：

我们已经解决了进程调度问题（非常重要）。 Linux 内核现在有足够的实时支持来确保进程在数据包准备好后立即获得 CPU。
时间戳，我是用tcpdump记录时间的。所以，这是在操作系统级别。但是，正如我所提到的，我们已经设置了实时优先级。我可以在不影响延迟的情况下大量加载盒子（CPU、磁盘和其他接口上的流量）。只有当我将流量添加到 SAME 接口时，我才会看到延迟受到影响。
有必要确切了解您的物理 IP 端口是什么品牌和版本（如果您有多个物理 IP 接口，您正在对其进行延迟测试）。当您有许多进程在同一个 CPU 上运行并使用同一个端口时，端口的工作方式很重要。如果它一次只能做一件事，它可能必须等到它完全发送一个大数据包，然后才能将接收到的数据包传递给操作系统（您在其中对其进行时间戳记）。您可以通过更改用于加载接口的流量的数据包大小来进行试验，看看这是否有效果。

【解决方案3】：

您是否尝试过抓包并检查 IP 标头的 TOS 值是否已更改？

您需要 linux 2.6.39 或更高版本才能使用 SO_PRIORITY。

您应该改为更改 IP_TOS。

你应该设置：

int iptos_precedence = 0xc0;
if (setsockopt(sock_fd, IPPROTO_IP, IP_TOS, &iptos_precedence, sizeof(iptos_precedence)) < 0) {
           //print errno (or something like that)
}

【讨论】：