マルチキャスト送信パフォーマンス

Question

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

しかし、マルチキャストメッセージを送信する時間は、送信間隔が長くなるにつれて増加することに気付きました。送信を頻繁に行うほど、送信コールを完了するのに要する時間が短くなります。

このアプリケーションを使用すると、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の両方から発生します。私たちは、Dell 1950サーバーとIntel Pro 1000デュアルポートネットワークカードを使ってテストを行っています。マイクロベンチマーキングは、特にJavaでは困難ですが、これはJITingやGCに関連するとは考えていません。 http://www.moneyandsoftware.com/2009/09/18/multicast-send-performance/

Answer 1

いくつかの説：

Javaコードと私はテストのために使用しているコマンドラインはである

私の最初の考えは、私は、キャッシングがここ因子であると考えることだった - 場合タスクや値がまだスタック上にあるか、または最近の短期間のメモリにある場合、それらをより高速に送信できることがわかります。時間が増えるにつれて、利用可能なチャンスが減少するので、平均的には時間がかかります。

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

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

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

幸運を祈る！

Answer 2

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

Answer 3

それが話題に29西でこの記事をチェックし、その特定のホスト上のNICとの合体割り込みのアーティファクトかもしれないが、彼らは待ち時間がE1000 NICに125マイクロ秒に増やすことができます方法を示し、

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

Answer 4

どのように送信を待っていますか？あなたはCPUをあきらめないように待っていますか？