ギガビット リンクからギガビットを取得できませんか?

ギガビット リンクからギガビットを取得できませんか?

LAN をギガビットにアップグレードしました。netperf では次のように説明しています。

前に:

marcus@lt:~$ netperf -H 192.168.1.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1) 
port 0 AF_INET : demo
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    10.02      94.13   

後:

marcus@lt:~$ netperf -H 192.168.1.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1) port 0 AF_INET : demo
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    10.01     339.15   

たった 340 Mbps ですか? どういうことですか?

背景情報: ギガビット スイッチを介して sheevaplug に接続しています。壁には Cat5e 配線があり、配線の長さはおそらく 30 フィートです。netperf に詳しくない方のために説明すると、netperf は非常に安定した結果を出す傾向があり、決して嘘をつくことはありません。

答え1

チェックアウトこのスレッド寄稿者の一人 (Frennzy) がこれを非常にうまく概説しています。引用します:

ギガビット イーサネットの「実際の」速度は...

1Gbps。

つまり、1 秒あたり 10 億ビットの速度でビットを転送することになります。

得られるデータ スループットの量は、さまざまな要因に関係します。

システムへの NIC 接続 (PCI と PCIe とノースブリッジなど)。

HDD スループット。

バスの競合。

レイヤー 3/4 プロトコルと関連するオーバーヘッド。

アプリケーション効率(FTP と SMB/CIFS など)

フレームサイズ。

パケットサイズの分布(総スループット効率に関連)

圧縮(ハードウェアおよびソフトウェア)。

バッファ競合、ウィンドウ処理など

ネットワーク インフラストラクチャの容量とアーキテクチャ (ポート数、バックプレーン容量、競合など)

つまり、テストしてみるまで、本当のところはわかりません。NetCPS は、他の多くのツールと同様に、この目的に適したツールです。

そして、これはスレッドの後半にあります(ハイライトは私によるものです):

そんな風に考えるのはやめてください。今すぐやめてください。皆さん。

1 秒あたりのキロバイトまたはメガバイトの転送量を知りたいと思うかもしれませんが、ネットワーク速度が一定であっても、実際にはその値は変動します。ネットワークの「速度」(1 秒あたりのビット数) は絶対的です。ネットワーク スループット (1 秒あたりの実際のペイロード データ) は絶対的ではありません。

OP さんへ: 一般的に、100Mbps から 1000Mbps に切り替えると、データ転送速度が速くなりますか? ほぼ間違いなく速くなります。理論上の最大値に近づくでしょうか? いいえ。それは価値があるでしょうか? それはあなたが決めることです。

ネットワーク速度について話したいのであれば、ネットワーク速度について話してください。データ スループットについて話したいのであれば、データ スループットについて話してください。この 2 つは 1 対 1 で結びついているわけではありません。

答え2

「理論上の最大値」という言葉はよく使われますが、イーサネット技術では実際に応用されています。イーサネットのような CSMA/CD システムでは、回線が持つトラフィックの帯域幅の約半分しか送信できず、通常はそれより少し少なくなります。その理由は、その「最大値」を超えようとすると、トランシーバがパケットを送信するよりも衝突を検出する回数が増えるためです。すると、指数バックオフが作用し、パケット送信がさらに低下します。トークン リングはこれを回避しましたが、独自の問題が多く、現在はあまり使用されていないと思います。イーサネット/IP が事実上の標準になりました。

T3 などのアップリンク テクノロジでは、各ワイヤで完全なスループットを可能にする非同期ペアを使用しますが、これもイーサネット ベースのプロトコルではありません。

基本的な標準イーサネット デバイスを使用している場合、常に「理論上の最大値」が存在します。

答え3

GbE のコンテキストで CSMA/CD について話すことはまったくの間違いです。ギガビット イーサネット、または「全二重」イーサネットは CSMA/CD を使用しません。また、GbE は半二重操作の理論的な可能性をまだ維持していますが、半二重を実行する実際の製品化された GbE キットがあったかどうかはまったくわかりません。

OP が 1000 Gbit/s リンクで 300 Mbit/s 程度しか達成できなかった理由については、netperf の実行前と実行後に TCP の netstat 統計情報を収集し、-c および -C グローバル コマンドライン オプションを含めて、両端の CPU 使用率を確認することをお勧めします。パケットがドロップされているか、片側または反対側の CPU が飽和状態になっている可能性があります。両端のシステムがマルチコアの場合は、外部ツールを使用するか、netperf デバッグ出力を調べて、コアごとの使用率を必ず確認してください。

その他の netperf に関する質問は、netperf.org メーリング リストの netperf-talk に残すのが最善でしょう。

関連情報