13

私の仕事では、tc は出力シェーピングを実行でき、入力ポリシングしか実行できないことがわかりました。なぜ tc が入力シェーピングを実装しないのだろうか?

コードサンプル:

#ingress
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 \
   u32 match ip src 0.0.0.0/0 police rate 256kbit \
   burst 10k drop flowid :1
#egress
tc qdisc add dev eth0 root tbf \
   rate 256kbit latency 25ms burst 10k

しかし、私はこれを行うことはできません:

#ingress shaping, using tbf
tc qdisc add dev eth0 ingress tbf \
   rate 256kbit latency 25ms burst 10k

IFB(更新された IMQ) と呼ばれるソリューションがトラフィックを出力にリダイレクトできることがわかりました。ただし、CPU を浪費しているため、良い解決策ではないようです。だからこれは使いたくない。

入力シェーピングは理にかなっていますか? そして、なぜ tc はそれをサポートしないのですか?

4

2 に答える 2

13

イングレスの tc シェーピング ルールは非常に限られていますが、ここで説明するように、仮想インターフェイスを作成してそれにエグレス ルールを適用できます。

https://serverfault.com/questions/350023/tc-ingress-policing-and-ifb-mirroring

(VM が既に仮想インターフェイスを使用していて、それらに tc を適用できる場合、仮想インターフェイスは必要ないかもしれません。)

入力シェーピングの注意点は、ストリーム ソースとインターフェイス間のルーター内のすべてのバッファーが原因で、着信ストリームがシェーピング アクションに応答するのに時間がかかる場合があることです。そして、ストリームが縮小された制限に応答するまで、ストリームは下流にあふれ続けます! その間、良いパケットを破棄することになり、スループットが低下します。

同様に、優先度の高いストリームが終了またはドロップオフすると、優先度の低いストリームがフルレートに戻るまでに時間がかかります。これが頻繁に発生する場合、これは非常に混乱を招く可能性があります。

この結果、ダイナミック シェイピングは、安定したレートの存続期間の長いストリームのグループでは必要に応じて機能する可能性がありますが、ダウンストリームがフラッディングされた場合、存続期間が短い、またはレートが変化する優先度の高いストリームにはほとんど利点がありません。優先度の低いストリームは、後退するのに時間がかかりすぎます。ただし、優先度の低いパケットと中程度の優先度のパケットを分類して、最大ダウンレートよりも低い静的レートに制限すると、優先度の高いデータ用に少なくともいくらかのスペースを確保するのに役立ちます。

これに関する数値はありませんが、レイテンシは ADSL の時代から大幅に改善されました。したがって、優先度の高いパケットの低レイテンシまたは高スループットが全体的なスループットよりも必要であり、上記の制限に耐えられる場合は、テストする価値があると思います.

Janoszen と ADSL HOWTO が言及しているように、シェーピングの一部として TCP ウィンドウ サイズを調整できれば、ストリームははるかに迅速に応答できます。

さらなる研究のためにTLDPを検索してください。

于 2013-06-06T01:12:13.353 に答える
4

シェーピングは送信バッファで機能します。入力シェーピングでは、リモート送信バッファを制御する必要があります。

于 2013-05-10T22:55:29.813 に答える