web-dev-qa-db-ja.com

誤った結果を与えるiperf

新しいブロードバンドをインストールしたばかりで、iperf3を使用してそのスループットをテストしたいと思いました。ただし、従来の速度テストとはかなり異なる結果が得られているようです。

E:\tmp> iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.01  sec  13.1 MBytes  11.0 Mbits/sec                  sender
[  4]   0.00-10.01  sec  13.1 MBytes  11.0 Mbits/sec                  receiver

オンライン速度テストでは、約150メガビットの期待される結果が示されています。

3.testdebit.infoはAzureからテストされており、一貫して約330Mビットです（ただし、それが何を意味するのかは誰にもわかりません）。

AzureでホストされているLinuxボックス（別のAzureボックスに最大100Mビットを配信する）など、さまざまなサーバーを試しました。これは、ISPスロットリングを除外するために、ポート80でも実行されました。これらの結果はすべて比較可能です。

210秒で3.5GBのファイルをダウンロードすると、約130Mビットになります

なぜiperf3がこんなに低いのか（または私は本当に愚かで何か間違ったものを読んでいるのか！）

これらはすべて同じコンピューター上にあり、イーサネット経由であるため、ワイヤレスなどが邪魔になりません。

追加するように編集

Iperf2（Windowsクライアント（iPerf 2.0.5-3）およびubuntu（iperfバージョン2.0.5））で同じテストを実行すると、これらの結果が得られます。

E:\tmp\iperf2> iperf -c <hidden>.cloudapp.net -p 5201
------------------------------------------------------------
Client connecting to <hidden>.cloudapp.net, TCP port 5201
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 51816 connected with <hidden> port 5201
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  12.1 MBytes  10.0 Mbits/sec

LinuxベースのNASからも同じことが実行されます

Nas:~# iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  14.5 MBytes  12.2 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  14.5 MBytes  12.2 Mbits/sec                  receiver

そして-Rフラグ付き

E:\tmp> iperf3 -c 3.testdebit.info -R
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  58.0 MBytes  48.6 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  57.0 MBytes  47.8 Mbits/sec                  receiver

サーバーの問題ではないことを確認するために、Azure VMを、3.testdebit.infoサーバーから600Mbitアップ/ 1Gbitダウンするサイズにアップグレードしました。

ジョン・ルッカーの答えに応えて

質問の私の主な目的は、なぜiperfがそのようなさまざまな結果をもたらしているのかを理解しようとすることでした。アップロードは頻繁に共有されており、あまり関心がないことを理解しています（または少なくとも別の質問です！）

私が使用していたAzureサーバーは、北ヨーロッパと西ヨーロッパ（アムステルダムとアイルランドだと思います）にあり、240Mb/sの領域でオンラインスピードテストが達成されました。

ただし、マルチスレッドが問題だったようです。デフォルトのスレッドの代わりに4つのスレッドを使用して、テストを再実行しました。

E:\tmp>iperf3 -c 3.testdebit.info -R -P 5
Connecting to Host 3.testdebit.info, port 5201
Reverse mode, remote Host 3.testdebit.info is sending
- - - - - - - - - - - - - - - - - - - - - - - - -
[SUM]   0.00-10.00  sec   195 MBytes   163 Mbits/sec   50             sender
[SUM]   0.00-10.00  sec   190 MBytes   160 Mbits/sec                  receiver
networkingperformanceiperf
3
Michael B
  1. 優れた従来の速度テストはマルチスレッドであり、速度テストサーバーへの複数の接続を作成します。したがって、接続を最大限に活用してその可能性を最大限に引き出します。

http://www.thinkbroadband.com/faq/sections/flash-speed-test.html#324

  1. iPerf3は（デフォルトオプションを使用して）2つの接続しか作成しないようです。これは、特に輻輳が発生した場合に、152Mbブロードバンドを最大化するには不十分な場合があります。

  2. ダウンロードテストでは、マルチスレッド接続も提案されています。

210秒で3.5GBのファイルをダウンロードすると、約130Mビットになります

しかし、あなたの計算は間違っています。

（（3.5GB x 8ビットx1024x1024x1024）/ 210s）/ 1000000Mbit = 143Mb/s平均。

152Mb層でのダウンロードには、平均速度143Mb/sが適しています。

152Mb層は161Mb/sのバーストダウンロード速度で最大になりますが（モデムは速度を保証するためにプロファイルが過剰になっています）、いくつかの要因により平均速度がわずかに遅くなることがよくあります。

  • サーバーによるレート制限。
  • TCP受信ウィンドウは、速度を上げるために時間が必要です。
  • ケーブルモデムの要求-許可サイクル。
  • ノードでの輻輳。ケーブル接続（したがってダウンストリームチャネル）を他の何百人もの人々と共有しています。ケーブルモデムでロックした8x 256 QAMダウンストリームチャネルの最大使用帯域幅は、ノードからの合計400Mbです。これは、あなたとあなたと同じチャネルを持つケーブル上の他のすべてのユーザーの間で共有されます。ダウンロード中に他のユーザーが接続を使用している場合、速度は当然少し異なります。
  • ルート上の混雑。
  • サーバーでの輻輳。
  • パケット損失と再送信。

アップストリーム帯域幅は、ノードへのケーブルで他のユーザーと激しく競合しています。

2 x 16 QAMアップストリームチャネルがロックされている場合、2 x 17Mb = 34Mbを他の多くのユーザーと共有しています。 2 x 64 QAMアップストリームチャネルがロックされている場合、2 x 27Mb = 54Mbを他の多くのユーザーと共有しています。

  1. 長距離では、遅延が達成可能な速度の要因になります。

英国、ヨーロッパ、アメリカのいずれであるかを問わず、使用しているAzureサーバーについては述べていません。

IPerf3サーバーはフランスにあり、場所に応じてLINXを経由する場合としない場合があります。ルートの輻輳は、特にピアリングポイントで、VMネットワークを離れると、問題になることがあります。

  1. 非標準ポートは、多くの場合、P2Pトラフィックとして扱われます。 http://www.thinkbroadband.com/faq/sections/flash-speed-test.html#32

ダウンロード、ストリーミング、ゲームなどのダウンストリームトラフィック管理はありませんが、30Mb以上の層では、トラフィックがP2Pとして分類されている場合、トラフィックが管理され、ピーク時に速度が低下します。

その理由は、アップストリームの帯域幅は数百人のユーザーによって共有されているため非常に不足しているため、アップストリームを圧倒する可能性のあるプログラムは、ケーブル上のすべての人にとって非常に悪いものになるためです。これが、アップストリームが依然としてトラフィック管理されている理由でもあります。

ピーク時間外は、好きな方法で接続を最大限に活用できるはずです。

  1. 小さいファイルサイズを使用するテストには注意してください。ここで使用できるテストファイルの範囲があります： http://www.thinkbroadband.com/download/

  2. ダウンロードがCDNによって配信されたり、VMネットワーク内にキャッシュされたりする可能性はほとんどありませんでした。152Mbを使用していたときは、サーバーから直接161Mbで定期的にダウンロードしてストリーミングしていました。もっと早く！

元の質問に答えるには、テスト戦略の詳細を提供する必要があります。

1
John Looker

IPerfのデフォルトは「アップロード」テストであることに注意してください。IPerfクライアント（-c）送信 TCPデータをIPerfサーバー（-s ）LAN上でクライアントを実行し、パブリックインターネットでホストされているIPerfサーバーに接続しているようです。そのため、ダウンロードではなく、新しいブロードバンド接続のアップロード速度をテストしていました。

ダウンロード速度をテストするには、-s/-cとして呼び出す端を逆にするか、-rを使用して、その後に「逆」（ダウンロード）テストを実行するように指定します。通常のテストを行います。

LANマシンがNATまたはファイアウォールの背後にある場合、ダウンロードテストを機能させるには、ポートを適切に開く/マップする/転送する必要がある場合があることに注意してください。

4
Spiff