Linux低延迟tcp流

Question

我有一个嵌入式应用程序，它有这样的要求:一个传出TCP网络流需要绝对最高的优先级，而不是所有其他传出网络流量。如果有任何数据包等待在该流上传输，则它们应该是发送的下一个数据包。句号。

我衡量成功的标准是:在没有后台流量的情况下测量高优先级延迟。添加背景流量，并再次测量。延迟的不同应该是发送一个低优先级数据包的时间。与100 With的链接，mtu=1500，这大约是150个我们。我的测试系统有两个通过交叉电缆连接的linux盒。

我已经尝试了很多很多事情，虽然我已经大大提高了延迟，但没有达到目标(我目前看到了5ms的附加延迟与背景流量)。我已经发布了另一个非常具体的问题，但是我认为我应该从一个一般性的问题开始。

第一个问题: Linux是否可能出现这种情况？第二个问题:如果是，我需要做什么？

我应该使用

• tc?
• What qdisc吗？
• 调整内核网络参数？哪些？
• ，我还缺什么东西？

谢谢你的帮忙!

埃里克

更新10/4/2010:我在发送端和接收端设置了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将其分解为多个数据包(为此测试将mtu设置为600 )。然而，这种情况发生在比流量控制更低的网络层，因此，我的延迟是由最大tcp传输数据包大小而不是mtu决定的！啊..。

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

Answer 1

您可能需要检查NIC驱动程序上的设置。一些驱动程序合并了中断，从而通过提高吞吐量来增加延迟。

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

另外，我不知道NIC是否在缓冲多个输出包，但如果是的话，这将使强制执行所需的优先级变得更加困难:如果NIC中存在多个低优先级的缓冲包，内核可能无法告诉NIC“忘记我已经发送给您的东西，先发送这个高优先级的数据包”。

-更新

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

ip route add default via 1.1.1.1 mtu 600

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