tcを使用したトラフィックシェーピングは、高い遅延と帯域幅では機能しません
トラフィックシェーピングにカーネル2.6.38.8でtcを使用しています。帯域幅の制限は機能し、遅延の追加は機能しますが、両方の帯域幅を遅延でシェーピングする場合、制限が1.5 Mbpsを超えると、達成される帯域幅は常に制限よりはるかに低くなります。
例：
tc qdisc del dev usb0 root
tc qdisc add dev usb0 root handle 1: tbf rate 2Mbit burst 100kb latency 300ms
tc qdisc add dev usb0 parent 1:1 handle 10: netem limit 2000 delay 200ms
201ミリ秒の遅延（pingから）を生成しますが、容量はわずか1.66 Mbps（iperfから）です。遅延をなくすと、帯域幅は正確に2Mbpsになります。 1Mbpsと200ms RTTの帯域幅を指定すると、すべてが機能します。同様の結果が得られるipfw/dummynetも試しました。
KconfigでHZ = 1000を使用してカーネルを再構築しようとしましたが、問題は解決しませんでした。他のアイデア？
アクセルを踏んでから車が速くなるまでに1秒の遅延があった場合、時速55マイルを正確に運転しようとしていると想像してみてください。あなたはそれをするのにかなり苦労するでしょう。
そして、少なくともあなたには、時速55マイルを運転する必要があるという利点があります知っている。さて、あなたがそれを知らないと想像してください。つまり、時速55マイルを超えると、停止して再び加速する必要があり、停止する速度がわからないということです。
確かに平均55ではないでしょうね。
ここでも同じです。 TCPスタックは、2MBpsに制限されていることを認識しておらず、その制限を見つけようとする必要があります。また、遅延は、制限に達したという情報に迅速に対応できないことを意味します。実際には2Mbpsを超えますが、ハード制限のため、その平均はそれよりも少なくなります。
burstおよび/またはminburstの設定でこれを改善できる場合があります。基本的に、それらが行うことは、接続が制限を下回っている場合、接続を制限を少し超えさせることです。このようにすると、2Mbpsを少し超える場合があり、その場合、平均で2Mbpsに近くなります。