アプリケーションのパフォーマンスをテストするには、高いレイテンシと低帯域幅接続をシミュレートする必要があります。私はこのコマンドを説明する多くのページを読みましたtc。ところで、私が設定した番号を確認することはできません。たとえば、
次のコマンド値を取得しました。 https://www.excentis.com/blog/use-linux-traffic-control-impairment-node-test-environment-part-2
tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms
これを（たとえばマシンA）に適用するときは、ページの説明に基づいて出力速度が128 kBps（少なくとも約128 kBps）でなければならないとします。これをテストするために、scpを使用してAマシンから同じLAN上の別のマシン「B」に2 GBのファイルを転送し始めました。ネットワークは、追加の損傷なしに最大12MBpsの転送速度を達成できます。しかし、転送が開始されると、速度は2MBpsであり、11kBpsから24kBpsの間で揺れて停止するまで停止して落ちます。
転送中に両方のネットワークスループットを監視するためにnmonを使用しましたが、24 kBpsを超えたことはありません（いくつかの54および62の読み取り値を除く）。
また、速度とバケットサイズを増やしましたが、scpの動作は同じです。バケットのサイズと速度を増やすために、次のコマンドを試しました。
tc qdisc add dev eth0 root tbf rate 1024kbps burst 1024kb latency 500
scpはまだ停止しており、同じ速度（11-30kBps）で変動しています。
ここで「金利」という言葉を推論するのは間違っていますか？ tcのマニュアルページを確認しましたが、私の説明は正しいようです。パラメータ設定をテストする最良の方法が何であるかを説明できる人はいますか（私が正しく実行していると仮定しています）？
答え1
遅延を引き起こすには、「netem」qdiscを使用する必要があります。
TBF qdiscの「遅延」パラメータは注意を喚起しました。 TBF qdiscsの場合、このパラメーターはキュー内のパケットに許可される最大遅延のみを設定します。たとえば、単一のパケットの待ち時間が400ミリ秒でキューが十分に深い場合、そのパケットはテールドロップされます。これは実際に望ましい高レイテンシをシミュレートするのに役立ちません。
次のようなものを使用することをお勧めします。
tc qdisc add dev eth0 root netem delay 400ms rate 1024kbps
注：キロビットを意味しますか？
tc ツールは、1 秒あたりのキロビットを「kbit」、1 秒あたりのキロバイトを「kbps」と表します。
答え2
@user144844 返信ありがとうございます。ちなみにnetem金利論争はありません。
tbfパラメータの私の理解は非常に明確です。また、latencyトークンバケットフィルタと一般的なネットワーク待ち時間の一部であることも知っています。前述のようにrate2GBファイルでテストすると、速度が設定された値に調整されるのを見ることができないことが問題です。scp
元の質問に戻り、私は実際のシミュレーションを進めることに決めました。最後に、rateスループットが968kbps（LAN条件下）から249kbps（適用速度を使用）に低下したため、設定が適用されたtbfことが明らかになりました。負荷をオリジナルより2倍、3倍に増やしても同じ状況が持続し、応答時間に影響を与えることがわかりました。したがって、私はパラメータセットが機能すると信じています。scpそれをテストする最良の方法ではありません。
次のコマンドを使用してネットワーク条件を設定します。
# tc qdisc add dev eth0 root handle 1: tbf rate 256kbit burst 256kbit latency 200ms
# tc qdisc add dev eth0 parent 1:1 handle 11: netem delay 50ms
# tc qdisc show
qdisc tbf 1: dev eth0 root refcnt 2 rate 256000bit burst 32Kb lat 200.0ms
qdisc netem 11: dev eth0 parent 1:1 limit 1000 delay 50.0ms