我有一个具有此要求的嵌入式应用程序：一个传出TCP网络流需要绝对最高优先级而不是所有其他传出网络流量。如果有任何数据包等待在该流上传输，则它们应该是下一个发送的数据包。周期。
我的成功衡量标准如下：在没有后台流量时测量高优先级延迟。添加后台流量，然后再次测量。延迟的差异应该是发送一个低优先级数据包的时间。使用100Mbps链路，mtu = 1500，大约150 us。我的测试系统有两个通过交叉电缆连接的linux盒子。
我已经尝试了很多很多东西，虽然我的延迟有很大提高，但还没有实现目标（我目前看到5毫秒的后台流量增加了延迟）。我已经发布了另一个非常具体的问题，但我想我应该从一个普遍的问题开始。
第一个问题：Linux可以实现吗？ 第二个问题：如果是这样，我需要做什么？
感谢您的帮助！
埃里克
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）将其分解为多个数据包。但是，这发生在 lower 网络层而不是流量控制，因此我的延迟是由最大tcp传输数据包大小决定的，而不是mtu！ Arghhh ..
任何人都知道在Linux上设置TCP的默认最大数据包大小的好方法吗？
答案 0 :(得分：1)
您可能想要检查NIC驱动程序的设置。一些驱动程序会合并中断，这会增加吞吐量，从而增加延迟。
http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html
另外，我不知道NIC是否正在缓冲多个输出数据包，但如果是，则会使执行所需优先级更加困难：如果NIC中有多个低优先级数据包缓冲，内核可能没有办法告诉网卡“忘记我已发送给你的东西，先发送这个高优先级的数据包”。
---更新---
如果问题是长TCP段，我相信您可以通过mtu上的ip route选项控制TCP层通告的最大段大小。例如：
ip route add default via 1.1.1.1 mtu 600
（请注意，您需要在接收方面执行此操作）。