Windowsで毎秒数百万のデータグラムを処理することは可能ですか？

数十または最大200のマルチキャストグループを使用して、高速UDPマルチキャストデータグラム（ほとんど100〜400バイト）を受信するHPCアプリをWindowsに実装できるかどうかを調査しています（つまり、MSI-XとRSSを使用して複数のコアに拡張）、パケットごとに処理を行ってから送信します。TCP経由で送信すると、壁にぶつかることなく（6.4Gb /秒）必要な範囲まで上昇しましたが、高いppsレートでデータグラムを受信することが問題であることが判明しました。

で、最近のテストのWindows 2012 R2上の2ポートを持つハイスペックNUMAマシン上での10GbイーサネットNIC、私はすることができた毎秒UDPデータグラムの数十万人受けし、実際にデータを処理せずに（早期低下、すなわち2x12コアを使用して、アプリの処理オーバーヘッドを式から削除して、取得速度を確認します。テストされた12のマルチキャストグループのカーネル部分は、1つのNUMAノードの8コアまたは10コアに分散しているように見えました（最大RSSキューが設定されていました） 16）-.netアプリではありますが、ネイティブアプリはより高速に動作するはずです。

しかし、たとえレンホルゲートは 唯一500kppsでUDPパケットを受信するために管理における彼の、高性能のWindows RIOテスト 1024バイトのUDPペイロードを使用して、。

でQLogicのホワイトペーパー（言及されていないテスト対象OS）「ルーティングマルチスレッド超小型パケット」の制限は、（受信及び送信以降の両方を含むように？）に設定されている5.7Mpps。で記事のLinuxのネットワーク、限界がに設定されている2Mppsに1Mppsコアあたり（伝え多かれ少なかれ直線的にスケールアップ）、あるいは15Mppsそのバイパスカーネルの特別なソリューションを。

例えばネットマップ

900Mhzで実行されている単一のコアを備えた10GigEリンクで、ラインレート（14.88Mpps）でトラフィックを生成できます。これはパケットあたり約60〜65クロックサイクルに相当し、コアとクロック周波数（4コアでは、450 MHz未満でラインレートが達成されます）に合わせて拡張できます。受信側でも同様のレートに達します。

では、Windows / Windows Server（の最新バージョン）、特に先行段落で説明したUDPマルチキャストの受信はどこまでできますか？

編集 Linuxでそれを行う方法について、cloudflareブログの投稿と興味深いコメントセクションがあります。1秒間に100万パケットを受信する方法、および対応するハッカーニュースのコメントページがあります。

Microsoftによると、自分の研究室でのテストがあったの「初期のテストでは、特定のサーバー上で」というRIO、彼らが扱うことができました

• Windows Server 2008R2で損失なしの 2Mpps、つまりRIOなし
• RIOを使用する4Mpps（プレリリース）Windows Server 8

そのビデオのスクリーンショット（44:33）：

したがって、私の質問への答えIs it possible to process millions of datagrams per second with Windows?は次のようになります。はい、そしてどうやらそれはRIOの前でさえ、Windows Server 2008R2でした。

しかし、特に発表されていないソフトウェアに関する公式の数字に加えて、このプレゼンテーションで与えられたわずかな情報だけで、ひとつまみの塩で撮影する必要があり、テストに関する多くの質問、したがって結果を適切に解釈する方法が残っています。最も関連するものは：

1. 送信用の数字はありますか？受信していますか？それとも、ルーティング（つまり、受信+送信）ですか？
2. パケットサイズは？->おそらく最も低いもので、一般にppsの数字を自慢しようとするときに行われます
3. どのように多くの接続/パケットストリーム（UDPの場合）（TCPの場合）？->おそらく、ワークロードを分散するために必要な数だけ、存在するすべてのコアを使用できるようにします
4. どのようなテスト設定ですか？マシンおよびNICの仕様と配線

送信と受信では異なる手順が必要であり、パフォーマンスに大きな違いがあるため、最初の手順は重要です。その他の数値については、可能な限り最大のMppsの数値を得るために、コアあたり少なくとも1つの接続/パケットストリームがある最低のパケットサイズがハイスペックマシンで使用されていると考えられます。

編集 Linuxでの高性能パケット処理に関するIntelのドキュメントを偶然見つけましたが、それに応じて（Linux）

プラットフォームは、1秒あたり約200万トランザクションのトランザクションレートを維持できます。

標準のLinuxネットワークスタックを使用する（2x8コアの物理ホスト上）。この要求/応答テストのトランザクションには両方が含まれます

1. UDPパケットの受信
2. そのパケットのその後の転送

（netperfのネットサーバーを使用）。このテストでは、100のトランザクションを並行して実行していました。興味がある人のために、この論文にはさらに多くの詳細があります。Windowsで比較するためにこのようなものがあればいいのに...とにかく、ここにその要求/応答テストに最も関連するチャートがあります。

tl; dr

明確な答えを出すには、さらにテストが必要だと思われます。しかし、状況証拠は、Linuxが超低遅延コミュニティで実際に排他的に使用されるOSであり、Mppsワークロードも定期的に処理することを示唆しています。これは、Windowsでは不可能という意味ではありませんが、Mpps数を達成することは可能かもしれませんが、Windowsはおそらくかなり遅れるでしょう。ただし、テストを確認する必要があります。たとえば、これらの数値を達成できるコスト（CPU）を把握する必要があります。

NBこれは、私が受け入れるつもりの答えではありません。この質問への回答に興味がある人に、私たちがどこにいるか、さらに調査する場所についてのヒントを提供することを目的としています。

グーグルによれば、Windowsネットワーキングのパフォーマンスを向上させるためにRIOをテストした（そして結果を公開した）唯一の人物であるLen Holgateは、彼のブログのコメントで、単一のIP / Portコンボを使用していることを明確にしたUDPパケットを送信します。

言い換えれば、彼の結果はLinuxでのテストのシングルコアの数値とある程度匹敵するはずです（ただし、彼は8つのスレッドを使用していますが、コードをまだチェックしていないので、単一のUDPパケットストリームのみを処理するときのパフォーマンスに有害なようです）パケットの重い処理を行っており、実際に使用されるスレッドはごくわずかであると述べていますが、これは理にかなっています）。それは彼が言っているにもかかわらずです：

古いAPIと新しいAPIの相対的なパフォーマンスを比較するためだけに最大限のパフォーマンスを得ようとはしていなかったので、テストではそれほど徹底的ではありませんでした。

しかし、「一生懸命に努力する」以外のより荒いRIOの世界のために、標準IOCPの（相対的な）快適ゾーンを放棄しているのは何ですか？少なくとも1つのUDPパケットストリームに関する限り。

彼が意味することは、RIOのいくつかのテストでさまざまな設計アプローチを試みたので、たとえば、NIC設定を微調整してパフォーマンスの最後の部分を絞り出さなかったということだと思います。これは、たとえば、受信バッファサイズの場合、UDP受信パフォーマンスとパケット損失の数値に大きなプラスの影響を与える可能性があります。

しかし、彼の結果を他のLinux / Unix / BSDテストの結果と直接比較しようとするときの問題は次のとおりです。ほとんどのテストは、「パケット/秒」境界をプッシュしようとするとき、可能な限り小さいパケット/フレームサイズ、つまりイーサネットを使用します64バイトのフレーム。Lenは1024バイトのパケット（-> 1070バイトのフレーム）をテストしました。これは（特にNo-Nagle UDPの場合）はるかに高い「1秒あたりのビット数」の数値を取得できますが、小さいパケットでは可能な限りpps境界を押し上げることはできません。したがって、これらの数値をそのまま比較するのは公平ではありません。

これまでのWindows UDP受信パフォーマンスの調査結果を要約すると、次のとおりです。

• 超低遅延および/または高スループットのアプリケーションを開発しようとするとき、実際にWindowsを使用している人はいません。最近ではLinuxを使用しています
• 実際には、実際の結果（つまり、単なる製品広告ではない）を含むすべてのパフォーマンステストとレポートは、LinuxまたはBSDで行われています（先駆者であり、少なくとも1つの参考資料を提供してくれたLenに感謝します！）
• WindowsのUDP（標準ソケット）はLinuxより高速/低速ですか？私はまだわからない、私自身のテストをしなければならないだろう
• Windowsでの高性能UDP（RIO対ネットマップ）は、Linuxより高速/低速ですか？Linuxは簡単に、900MHzの、Windowsのではシングルコアとの完全な10Gbの回線速度を扱うに公表最良の場合 1024年の大規模なUDPパケットサイズのために43％または492kppsまで行くことができている、小さなサイズのため、すなわちbpsの数字はおそらく大幅になりますさらに悪いことに、ppsの数値はおそらく上昇します（割り込み処理またはその他のカーネルスペースのオーバーヘッドが制限要因でない限り）。

Linuxを使用する理由については、NetmapやRIOのようなカーネルの変更を伴うソリューションの開発-パフォーマンスを限界に押し上げる場合に必要-Windowsのような閉鎖システムでは、給与がレドモンドから発生しない限り、ほぼ不可能であるため、または、マイクロソフトと何らかの特別な契約を結んでいます。これが、RIOがMS製品である理由です。

最後に、私が発見したことのいくつかの極端な例を挙げただけで、Linuxランドで進行中です。

すでに15年前、800 mHzのPentium III CPU、 1 GbE NICの133 mHzのフロントサイドバスを使用して680kppsを受信して​​いた人もいました。 編集：彼らはClickを使用していました。これは、標準ネットワークスタックの多くをバイパスするカーネルモードルーターです。つまり、「だまされました」。

2013年に、アルゴンデザインが管理を取得します

最低35ns [ナノ秒]のレイテンシーを取引するためにチェックします

ところで彼らはまた

現在の取引用の既存のコンピューティングコードの大部分は、x86プロセッサアーキテクチャ上のLinux用に記述されています。

およびArgonは、（FPGAに加えて）OSを備えたArista 7124FXスイッチを使用します

標準のLinuxカーネルの上に構築されています。

さまざまな構成とシナリオを「測定」する必要があります。これは、2つの会社が提供する2つのギアを使用して行うことができます。IXIAおよびSpirent。これらは、回線速度でトラフィックをポンピングできるハードウェアベースのトラフィックジェネレーターを提供します。特定のシステムが崩壊する可能性のある速度を検出できるランプテストを提供します。デバイスは高価ですが、レンタルできます。