Windows上でHPCアプリを実装できるかどうか調査中です。12 個から最大 200 個のマルチキャスト グループを使用して、小さな UDP マルチキャスト データグラム (主に 100 ～ 400 バイト) を高速で受信します。(つまり、MSI-X と RSS を使用すると複数のコアに拡張できます)、パケットごとに何らかの処理を行ってから送信します。TCP 経由で送信すると、壁にぶつかることなく必要な速度 (6.4Gb/秒) まで上げることができましたが、高い pps レートでデータグラムを受信すると問題が発生することがわかりました。
で最近のテストWindows 2012 R2の2ポート10GbイーサネットNICを搭載した高性能NUMAマシンでは、1秒間に数十万のUDPデータグラムを受信する(早期ドロップ、つまり実際にデータを処理せずに、アプリの処理オーバーヘッドを方程式から取り除いて、どれだけ速くなるかを確認する) 2x12 コアを使用して、テストした 12 のマルチキャスト グループのカーネル部分は、1 つの NUMA ノードの 8 または 10 コアに分散されているように見えました (最大 RSS キュー16 に設定されています) - ただし、.net アプリの場合、ネイティブ アプリの方が高速になるはずです。
それでもレン・ホルゲート UDPパケットを500kppsでしか受信できなかったで高性能Windows RIOテスト1024 バイトの UDP ペイロードを使用します。
でQLogicのホワイトペーパー（テスト対象のOSは言及されていない）「マルチスレッドの超小型パケットルーティング」（つまり受信とその後の送信の両方を含む？）の制限は次のように設定されている。5.7Mpps。 で記事の上Linux ネットワーク、制限は1Mpps～2Mppsコアあたり（報告によるとほぼ直線的に拡大）、あるいは15Mppsカーネルをバイパスする特別なソリューションを使用します。
例えばネットマップ
ラインレートでトラフィックを生成できる（14.88Mpps) を 10GigE リンクで実行し、コアが 1 つだけ 900Mhz で動作している場合、パケットあたり約 60 ～ 65 クロック サイクルになります。これは、コアとクロック周波数に応じて適切にスケーリングされます (コアが 4 つの場合、ライン レートは 450 MHz 未満で達成されます)。受信側でも同様のレートが達成される。
では、Windows / Windows Server (最新バージョン) を、特に冒頭の段落で説明されているように UDP マルチキャストを受信することで、どこまで実現できるのでしょうか?
編集Linux でこれを行う方法については、cloudflare のブログ投稿と興味深いコメント セクションがあります。1秒間に100万パケットを受信する方法、そしてそれに対応するハッカーニュースコメントページ。
答え1
マイクロソフトによると、同社の研究室でのテストでは示した「初期テスト中の特定のサーバー」のリオ、彼らは対処することができた
- ロスなしで2MppsWindows Server 2008R2（RIOなし）
- RIO を使用した (プレリリース) Windows Server 8 で 4Mpps
そのビデオのスクリーンショット（44:33）：
私の質問に対する答えはIs it possible to process millions of datagrams per second with Windows?だろう：はいどうやら、RIO 以前の Windows Server 2008R2 でもそうだったようです。
しかし、特に未発表のソフトウェアに関する公式の数字は疑わしい上に、このプレゼンテーションで提供される情報はわずかしかないため、テストに関する多くの疑問、つまり結果を適切に解釈する方法がまだ残っています。最も関連性の高いものは次のとおりです。
- 数字は送信用ですか？受信用ですか？それともルーティング（受信 + 送信）用でしょうか?
- パケットサイズはどれくらいですか?-> おそらく可能な限り低い値であり、自慢できるようなPPS数値を得ようとするときに一般的に行われる。
- 接続数（TCPの場合）/パケットストリーム数（UDPの場合）? -> おそらく、存在するすべてのコアを使用できるようにワークロードを分散するために必要な数だけ
- どのようなテスト設定ですか?マシンとNICの仕様と配線
最初の項目は非常に重要です。送信と受信には異なる手順が必要であり、パフォーマンスに大幅な違いが出る可能性があるからです。その他の数値については、可能な限り最大の Mpps 数値を得るために、高性能マシンでコアあたり少なくとも 1 つの接続/パケット ストリームを備えた最小のパケット サイズが使用されていたと推測できます。
編集偶然、Intelの文書を見つけました高性能パケット処理Linux上で、それによると、(Linux)
プラットフォームは1秒あたり約200万件のトランザクションレートを維持できる
標準のLinuxネットワークスタック（2x8コアの物理ホスト上）を使用する。このリクエスト/応答テストのトランザクションには、
- UDPパケットの受信
- そのパケットのその後の転送
(netperf の netserver を使用)。テストでは 100 のトランザクションを並列で実行しました。興味のある方のために、論文にはさらに多くの詳細が記載されています。Windows で比較できるこのようなものがあればいいのですが... とにかく、この要求/応答テストに最も関連のあるグラフを以下に示します。
答え2
要約
明確な答えを出すには、さらにテストが必要と思われます。しかし、状況証拠から、Linux は超低遅延コミュニティで事実上独占的に使用されている OS であり、日常的に Mpps のワークロードも処理していることがわかります。これは Windows では不可能ということではありません。ただし、Mpps の数値を達成できる可能性はあるものの、Windows はかなり遅れをとることになるでしょう。しかし、それを確かめるにはテストが必要であり、たとえば、それらの数値をどの程度の (CPU) コストで達成できるかを把握する必要があります。
注: これは私が受け入れるつもりの回答ではありません。質問の回答に関心のある方に、私たちの立場とさらに調査すべき点についてのヒントを与えることを目的としています。
Googleによると、Windowsネットワークのパフォーマンスを向上させるためにRIOをテストした唯一の人物であるLen Holgateは、彼のブログにコメントするUDP パケットの送信に単一の IP/ポートの組み合わせを使用していた。
つまり、彼の結果はLinuxのテストにおけるシングルコアの数値とほぼ同等であるはずだ。(彼は 8 つのスレッドを使用していますが、まだコードをチェックしていないのでわかりませんが、単一の UDP パケット ストリームを処理し、パケットの重い処理を行わない場合はパフォーマンスに悪影響を与えると思われます。また、実際に使用されるスレッドはわずかであると述べており、これは理にかなっています)。彼は次のように言っているにもかかわらず、そうなのです。
私は、古い API と新しい API の相対的なパフォーマンスを比較するだけで、最大のパフォーマンスを得ようとそれほど努力していなかったため、テストはそれほど徹底していませんでした。
しかし、標準的なIOCPの（相対的な）快適ゾーンを放棄して、より過酷なRIOの世界へ「一生懸命努力する」以外に何かありますか? 少なくとも単一の UDP パケット ストリームに関する限りはそうです。
彼が言いたいのは、RIOのいくつかのテストでさまざまな設計アプローチを試したので、例えばNIC設定を微調整してパフォーマンスを最大限まで引き出すことはしなかったということだと思います。受信バッファサイズUDP 受信パフォーマンスとパケット損失の数値に大きなプラスの影響を与える可能性があります。
しかし、彼の結果を他の Linux/Unix/BSD テストの結果と直接比較しようとすると、次のような問題が生じます。ほとんどのテストでは、「1 秒あたりのパケット数」の限界を押し上げようとする際に、可能な限り小さいパケット/フレーム サイズ、つまり 64 バイトの Ethernet フレームを使用します。Len は 1024 バイトのパケット (-> 1070 バイトのフレーム) をテストしましたが、これは (特に No-Nagle UDP の場合)、はるかに高い「1 秒あたりのビット数」の数値を得ることができますが、小さいパケットの場合ほど pps の限界を押し上げることができない可能性があります。したがって、これらの数値をそのまま比較するのは公平ではありません。
これまでの Windows UDP 受信パフォーマンスの調査結果をまとめると次のようになります。
- 超低レイテンシや高スループットのアプリケーションを開発する際に、Windowsを使用する人は実際には誰もいません。最近ではLinuxが使用されています。
- 最近では、実際の結果を伴うパフォーマンス テストやレポート (単なる製品広告ではないもの) は、ほとんどすべて Linux または BSD で行われています (先駆者であり、少なくとも 1 つの参照ポイントを提供してくれた Len に感謝します)。
- Windows の UDP (標準ソケット) は Linux より速い/遅いですか? まだわかりません。自分でテストする必要があります。
- Windows 上の高性能 UDP (RIO vs netmap) は Linux よりも速い/遅いですか? Linux簡単に900MHzのシングルコアで10Gbのフルラインスピードを処理、Windowsではベストケースが発表された1024 の大きな UDP パケット サイズでは、最大 43% または 492kpps まで向上します。つまり、小さいサイズの bps 数値は大幅に悪化する可能性がありますが、pps 数値はおそらく上昇します (割り込み処理またはその他のカーネル空間のオーバーヘッドが制限要因でない限り)。
彼らが Linux を使用する理由は、パフォーマンスを限界まで押し上げるときに必要な、netmap や RIO などのカーネル変更を伴うソリューションの開発が、給料がたまたまレドモンドから支払われるか、Microsoft と特別な契約を結んでいるのでない限り、Windows のようなクローズド システムではほぼ不可能だからでしょう。RIO が MS 製品であるのはそのためです。
最後に、Linux の世界で起こっていること、そして現在起こっていることに関して私が発見した極端な例をいくつか挙げます。
すでに15年前には、680kppsの電力を800 mHz Pentium III CPU、133 mHz フロントサイドバス1GbE NIC 上。 編集: 彼らは使用していたクリック、標準ネットワーク スタックの多くをバイパスするカーネル モード ルーター、つまり「不正行為」です。
2013年、アルゴンデザイン管理された取得するため
取引の遅延は 35ns [ナノ秒] まで短縮
ちなみに彼らはまたこう主張している
現在、取引用の既存のコンピューティング コードの大部分は、x86 プロセッサ アーキテクチャ上の Linux 用に書かれています。
アルゴンはArista 7124FX スイッチ、FPGAに加えてOSも搭載
標準の Linux カーネル上に構築されています。