この要件を持つ組み込みアプリケーションがあります。1 つの発信 TCP ネットワーク ストリームは、他のすべての発信ネットワーク トラフィックよりも絶対的に高い優先度を必要とします。そのストリームで転送を待機しているパケットがある場合、それらは次に送信されるパケットになります。限目。
私の成功の尺度は次のとおりです。バックグラウンド トラフィックがない場合に優先度の高いレイテンシを測定します。バックグラウンド トラフィックを追加して、再度測定します。遅延の差は、優先度の低いパケットを 1 つ送信する時間になります。100Mbps リンクの場合、mtu=1500 で、およそ 150us です。私のテスト システムには、クロスオーバー ケーブルで接続された 2 つの Linux ボックスがあります。
私は非常に多くのことを試しましたが、レイテンシーは大幅に改善されましたが、目標を達成していません (現在、バックグラウンド トラフィックで 5 ミリ秒のレイテンシーが追加されています)。すでに別の非常に具体的な質問を投稿しましたが、一般的な質問からやり直す必要があると考えました。
最初の質問: これは Linux で可能ですか? 2 番目の質問: もしそうなら、私は何をする必要がありますか?
- 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 に設定しました) に基づいて複数のパケットに分割されます。ただし、これはトラフィック制御よりも下位のネットワーク層で発生するため、遅延は mtu ではなく最大 tcp 送信パケット サイズによって決定されます。ああああ..
LinuxでTCPのデフォルトの最大パケットサイズを設定する良い方法を知っている人はいますか?