Linux 低延迟 tcp 流

Question

我有一个具有此要求的嵌入式应用程序:一个传出 TCP 网络流需要绝对高于所有其他传出网络流量的优先级。如果该流上有任何数据包等待传输，它们应该是下一个发送的数据包。期间。

我衡量成功的标准如下:在没有后台流量时测量高优先级延迟。添加背景流量，并再次测量。延迟的差异应该是发送一个低优先级数据包的时间。对于 100Mbps 链路，mtu=1500，大约是 150 us。我的测试系统有两个通过交叉电缆连接的 linux 盒子。

我已经尝试了很多很多事情，虽然我已经大大改善了延迟，但还没有达到目标(我目前看到后台流量增加了 5 毫秒的延迟)。我已经发布了另一个非常具体的问题，但我认为我应该从一个一般性问题开始。

第一个问题:这在 Linux 上可行吗？第二个问题:如果可以，我需要做什么？

• tc?
• 我应该使用什么 qdisc？
• 调整内核网络参数？哪些？
• 我还缺少什么？

感谢您的帮助!

埃里克

2010 年 10 月 4 日更新:我在发送端和接收端都设置了 tcpdump。这是我在传输端看到的(那里似乎很拥挤):

0 us   Send SCP (low priority) packet, length 25208
200 us Send High priority packet, length 512

在接收端，我看到:

~ 100 us  Receive SCP packet, length 548
170 us    Receive SCP packet, length 548
180 us    Send SCP ack
240 us    Receive SCP packet, length 548
...  (Repeated a bunch of times)
2515 us   Receive high priority packet, length 512

问题似乎是 SCP 数据包的长度(25208 字节)。这被分解成基于 mtu 的多个数据包(我为这个测试设置为 600)。但是，这发生在比流量控制更低的网络层中，因此我的延迟是由最大 tcp 传输数据包大小决定的，而不是 mtu!啊……

有人知道在 Linux 上为 TCP 设置默认最大数据包大小的好方法吗？

Answer 1

您可能需要检查 NIC 驱动程序的设置。一些驱动程序合并中断，以更高的吞吐量换取增加的延迟。

http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html

此外，我不知道 NIC 是否正在缓冲多个输出数据包，但如果是，那将更难强制执行所需的优先级:如果 NIC 中缓冲了多个低优先级数据包，则内核可能没有办法告诉 NIC“忘记我已经发送给你的那些东西，先发送这个高优先级数据包”。

---更新---

如果问题是长 TCP 段，我相信您可以通过 ip route 上的 mtu 选项来控制 TCP 层通告的最大段大小。例如:

ip route add default via 1.1.1.1 mtu 600

(请注意，您需要在接收 端执行此操作)。