tcトラフィックの形成にHTBとCQBを使用すると、一貫性のないパケット転送間隔が発生します。

tcトラフィックの形成にHTBとCQBを使用すると、一貫性のないパケット転送間隔が発生します。

重複したらすみませんhttps://serverfault.com/q/1076769/822163。私は最初にそれを作成し、LinuxとUnix用のStack Exchangeが正しい場所であることに気づきました。問題:トラフィックを調整するためにtc HTBまたはCQBを使用すると、特定の間隔の後に送信された最初の2つのパケットがpcapログに記録されているとおりに連続的に送信されます。ネットワーク転送が有効なUbuntu 18.4中間コンピュータがあります。私は、送信ポートで一定のビットレート出力を持つようにトラフィックを形成するためにHTBを使用してtcを実行しています。クライアントはサーバーに可変サイズのチャンクを要求します。サーバーは、各チャンク間で200ms間隔で送信エンコードされたデータチャンクをクライアントに送信します。中間コンピュータを使用した設定の場合、これらのパケットは中間コンピュータのトラフィックシェーパを介して転送され、500kbpsの固定ビットレートが得られます。オフロード(TSOとGRO)を無効にすると、すべてのnバイトがpcapによってフレーム化されます。ほとんどの1448Bパケットの時間間隔は24.224msに近く、これは500kbpsと予想されます。

問題:フレームが順番に到着しても、時間間隔が一貫しないように到着します。 200ms間隔の後の2番目の大きなパケット(1448B)は、常に最初のパケットとほぼ連続します。遅く到着するブロック654Bの最後のパケットのスクリーンショット(添付の図の例では10.464msではなく24.224ms) パケット間の時間間隔。

HTBを使用したTCコマンド:

tc qdisc del dev eno1 root 2> /dev/null > /dev/null
tc qdisc add dev eno1 root handle 1:0 htb default 2
tc class add dev eno1 parent 1:1 classid 1:2 htb rate 500kbit ceil 500kbit burst 10 cburst 10 prio 2
tc filter add dev eno1 protocol ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:2

計算に間違いがなければ、トラフィックシェーピングに使用しているTCのトークン処理によって問題が発生した可能性があると思います。アイドル時間中にトークンが蓄積され、次のパケットが受信されると、連続して2つのパケットを送信するようです。 3番目のパケットからトークン消費率が安定します。この場合、ブロックの2番目のパケットに累積トークンを使用しないようにする方法があるかどうかを知りたいと思います。

tcコマンドでさまざまなオプションを試してみましたが、以下のCQB - コマンドリファレンスも試してみました。https://lartc.org/lartc.html#AEN2233

観察:バースト= 10を減らすと、最初のパケットと2番目のパケットの間隔がわずかに増加します。 TCとCQB:

tc qdisc del dev eno1 root 2> /dev/null > /dev/null
tc qdisc add dev eno1 root handle 1: cbq avpkt 5000 bandwidth 10mbit
tc class add dev eno1 parent 1: classid 1:1 cbq rate 500kbit allot 5000 prio 5 bounded isolated
tc class add dev eno1 parent 1:1 classid 1:10 cbq rate 500kbit allot 5000 prio 1 avpkt 5000 bounded
tc class add dev eno1 parent 1:1 classid 1:20 cbq rate 500kbit allot 5000 avpkt 5000 prio 2
tc filter add dev eno1 protocol ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:10
tc filter add dev eno1 parent 1: protocol ip prio 13 u32 match ip dst 0.0.0.0/0 flowid 1:20

追加: 提案されているようにhttp://linux-ip.net/articles/hfsc.en/HFSC(参照)を使ってみました。 HFSCの助けが必要です。これは私が使用するスクリプトです。

tc qdisc del dev eno1 root 2> /dev/null > /dev/null
tc qdisc add dev eno1 root handle 1: hfsc
tc class add dev eno1 parent 1: classid 1:1 hfsc sc rate 1000kbit ul rate 1000kbit
tc class add dev eno1 parent 1:1 classid 1:10 hfsc sc rate 1000kbit ul rate 1000kbit
tc class add dev eno1 parent 1:1 classid 1:20 hfsc sc rate 10000kbit ul rate 10000kbit
tc class add dev eno1 parent 1:10 classid 1:11 hfsc sc umax 1480b dmax 53ms rate 400kbit ul rate 1000kbit
tc class add dev eno1 parent 1:10 classid 1:12 hfsc sc umax 1480b dmax 30ms rate 100kbit ul rate 1000kbit
tc filter add dev eno1 protocol ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:11

私の結果

tc class show eno1

出力:

class hfsc 1:11 parent 1:10 sc m1 0bit d 23.4ms m2 400Kbit ul m1 0bit d 0us m2 1Mbit 
class hfsc 1: root 
class hfsc 1:1 parent 1: sc m1 0bit d 0us m2 1Mbit ul m1 0bit d 0us m2 1Mbit 
class hfsc 1:10 parent 1:1 sc m1 0bit d 0us m2 1Mbit ul m1 0bit d 0us m2 1Mbit 
class hfsc 1:20 parent 1:1 sc m1 0bit d 0us m2 10Mbit ul m1 0bit d 0us m2 10Mbit 
class hfsc 1:12 parent 1:10 sc m1 394672bit d 30.0ms m2 100Kbit ul m1 0bit d 0us m2 1Mbit

これが何を意味するのかよく分からない。

ul m1 0ビットd 0us

私のtcコマンドに

sc umax 1480b dmax 53ms

このスクリプトを実行した後、192.168.1.102でpingを試みます。 ping応答がほとんどなく、ARPが表示されます。

192.168.2.100の人は誰ですか?

192.168.2.100は私がtcを実行しているIP転送ポートのIPアドレスです。

このコマンドは主にhttp://linux-ip.net/articles/hfsc.en/ ちょうどパスを追加しました。

TC フィルタ dev eno1 プロトコル追加 ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:11

誰でもumaxとdmaxの問題を助けることができればいいでしょう。

ベストアンサー1

おすすめ記事