5

最近、マルチキャスト送信パフォーマンスの分析を完了しました。幸い、JavaとCは、WindowsとSolarisで異なるトラフィック送信速度をテストしたため、ほぼ同じように機能しました。

ただし、送信間の時間が長くなると、マルチキャストメッセージを送信する時間が長くなることに気付きました。sendを頻繁に呼び出すほど、send呼び出しを完了するのにかかる時間は短くなります。

このアプリケーションを使用すると、sendを呼び出すまでの待機時間を制御できます。以下では、パケット間の遅延が増加するにつれて時間が増加します。1000パケット/秒（1ミリ秒の待機時間）を送信する場合、送信を呼び出すのに13マイクロ秒しかかかりません。1パケット/秒（1000ミリ秒の待機時間）では、その時間は20マイクロ秒に増加します。

Wait time (ms)                      us to send
0                                   8.67   
1                                   12.97  
10                                  13.06  
100                                 18.03  
1000                                20.82
10000                               57.20

この現象は、JavaとCの両方、およびWindowsとSolarisの両方で見られます。IntelPro1000デュアルポートネットワークカードを搭載したDell1950サーバーでテストしています。マイクロベンチマークは、特にJavaでは難しいですが、これはJITやGCに関連しているとは思われません。

テストに使用しているJavaコードとコマンドラインは次の場所にあります：http ：//www.moneyandsoftware.com/2009/09/18/multicast-send-performance/

4

4 に答える 4

3

これは、その特定のホスト上のNICとの割り込み合体のアーティファクトである可能性があります。このトピックについては、29 Westによるこの記事を確認してください。これらは、e1000NICで遅延が125μsに増加する可能性があることを示しています。

http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html

于 2010-02-06T05:06:44.137 に答える
2

いくつかの理論：

私が最初に考えたのは、ここではキャッシュを要因と見なすということでした。タスクと値がまだスタック上にあるか、最近の短期記憶にある場合は、それらをより速く送信できる可能性があります。時間の経過とともに、まだ利用できる可能性は低くなるため、平均して時間がかかります。

ただし、これが当てはまる場合は上限があると思います...常にキャッシュにある時点です。

別の理由は、アプリ/テスト/プラットフォームで時間の経過とともにメモリリークまたはパフォーマンスの低下が発生することです。これは、（存在する場合）待機時間が長くなるほど、パフォーマンスが低下する時間が長くなり、送信に時​​間がかかることも意味します。

また、パケットの送信に時間がかかる場合は、アドレス学習のタイムアウトを超える可能性があります。IPテーブルとMACテーブルの両方です。これらのテーブル/キャッシュの有効期限が切れている場合は、パケットを転送する前にそれらを再学習する必要があります。

幸運を！

于 2009-09-18T14:37:02.930 に答える
1

これらのタスクを実行するためのコードは、呼び出しが発生したばかりのときにCPUの近くにキャッシュされます（おそらくまだレジスターにあります）。

于 2009-09-18T14:40:23.363 に答える
1

送信の合間にどのように待っていますか？CPUをあきらめないようにビジーウェイトを試しましたか？

于 2010-02-06T09:22:15.733 に答える