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

Question

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

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

しかし Len Holgate 500kppsでUDPパケットを受信するだけで管理されました彼の高性能Windows RIOテスト、1024のUDPペイロードを使用バイト。

QLogicのホワイトペーパー（テスト中のOSは言及されていません）「マルチスレッドの超小型パケットルーティング」の制限（受信と後続の送信の両方を含む）は5.7Mppsに設定されています。 articles on Linux network では、制限はコアごとに1Mppsから2Mppsに設定されています（伝えられるところによると、ほぼ直線的にスケールアップします）。15Mppsでも、カーネルをバイパスする特別なソリューションを使用します。

例えば。 netmap

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

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

EditLinuxでの実行方法に関するcloudflareブログの投稿と興味深いコメントセクションがあります： 1秒あたり100万パケットを受信する方法、そして対応するものがありますハッカーニュースコメントページ。

Eugene Beresovsky · Answer

Microsoftによると、ラボでのテスト表示「初期テストの特定のサーバーで」 [〜＃〜] rio [〜＃〜] 、扱う

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

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

enter image description here

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

しかし、公式の数字、特に未リリースのソフトウェアでは、このプレゼンテーションで提供される情報がまばらであるため、ほんの少しの塩で撮影する必要があることに加えて、テストに関する多くの質問、したがって結果を適切に解釈する方法が残っています。最も関連するものは次のとおりです。

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

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

編集Linuxで High Performance Packet Processing に関するIntelのドキュメントを偶然見つけました。それによると、（Linux）

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

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

uDPパケットの受信
そのパケットのその後の転送

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

enter image description here

Eugene Beresovsky · Answer

tl; dr

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

N.B.これは私が受け入れるつもりの答えではありません。これは、質問への回答に関心のある人に、私たちがどこに立っているのか、さらに調査する場所についてのヒントを与えることを目的としています。

グーグルによると、Windowsネットワークからより多くのパフォーマンスを得るためにRIOをテストした（そして結果を公開した）唯一の人のように見えるレン・ホルゲートは、彼のブログへのコメントで彼がUDPパケットの送信に単一のIP /ポートコンボを使用します。

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

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

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

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

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

これまでのWindows UDPへの私の探求の結果を要約すると、これまでのところパフォーマンスを受信します。

超低遅延および/または高スループットのアプリケーションを開発しようとするときに、実際にWindowsを使用している人は誰もいません。最近では、Linuxを使用しています。
最近の実質的にすべてのパフォーマンステストと実際の結果を伴うレポート（つまり、単なる製品広告ではない）はLinuxまたはBSD上にあります（パイオニアであり、少なくとも1つの参照ポイントを提供してくれたLenに感謝します！）
WindowsのUDP（標準ソケット）はLinuxよりも速い/遅いですか？まだわかりませんが、自分でテストする必要があります
Windowsの高性能UDP（RIOとネットマップ）はLinuxよりも高速/低速ですか？ Linux 簡単 Windowsでは、900MHzのシングルコアでフル10Gbの回線速度を処理しますベストケースの公開は、大きなUDPパケットで最大43％または492kppsサイズが1024の場合、つまり、小さいサイズのbpsの数値はおそらく大幅に悪化しますが、ppsの数値はおそらく上昇します（割り込み処理またはその他のカーネルスペースのオーバーヘッドが制限要因である場合を除く）。

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

最後に、私が発見したものとLinuxで起こっていることのいくつかの極端な例を挙げます。

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

2013年、Argon Design managed 取得する

35ns [ナノ秒]という低いレイテンシーをトレードするためにティック

ところで、彼らはまた、

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

アルゴンは Arista 7124FXスイッチを使用し、（FPGAに加えて）OSを持っている

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

Pat · Answer

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