アプリケーションのパフォーマンスをテストするには、高いレイテンシと低帯域幅接続をシミュレートする必要があります。私はこのコマンドを説明する多くのページを読みました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」と表します。