4

我正在构建一个具有各种网络流量的实时嵌入式 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 机器使用相同的 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 不帮助我？我错过了什么？

谢谢！

埃里克

4

3 回答 3

0

您是否尝试过捕获数据包并检查 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)
}
于 2014-04-01T09:47:06.313 回答
0

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

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

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

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

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

于 2010-11-01T14:54:51.317 回答
0

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

于 2010-09-21T01:06:43.493 回答