我正在研究是否可以在 Windows 上實現 HPC 應用程式使用十幾個或多達 200 個多播組以高速率接收小型 UDP 多播資料報（主要是 100-400 位元組）（即使用 MSI-X 和 RSS，我可以擴展到多個核心），對每個資料包進行一些處理，然後將其發送出去。透過 TCP 發送，我成功地達到了我需要的速度（6.4Gb/秒），而沒有碰壁，但以高 pps 速率接收資料報卻是一個問題。
在一個最近的測試在 Windows 2012 R2 上具有 2 連接埠 10Gb 乙太網路 NIC 的高規格 NUMA 電腦上，我只能每秒接收數十萬個 UDP 資料報（早期下降，即沒有實際處理數據，從等式中刪除我的應用程式的處理開銷，看看它的速度有多快）使用2x12 核心，並且測試的12 個多播組的內核部分似乎分佈在8 個或1 個 NUMA 節點 10 個核心（最大 RSS 佇列數設定為 16) - 儘管使用的是 .net 應用程序，因此本機應用程式應該能夠運行得更快。
但即使倫霍爾蓋特 只能以 500kpps 的速度接收 UDP 封包在他的高效能 Windows RIO 測試，使用 1024 位元組的 UDP 有效負載。
在QLogic 的白皮書（未提及測試中的作業系統）「多執行緒超小資料包路由」的限制（因此包括接收和後續發送？）設定為5.7Mpps。在文章在Linux網路，限制設定為1Mpps 至 2Mpps每個核心（據報導或多或少線性擴展），甚至15Mpps使用繞過內核的特殊解決方案。
例如網路圖
可以線速產生流量（14.88Mpps）在 10GigE 鏈路上，只有一個以 900Mhz 運行的核心。這相當於每個資料包大約 60-65 個時脈週期，並且可以根據內核和時脈頻率很好地擴展（使用 4 個內核，可以在低於 450 MHz 的情況下實現線路速率）。接收端達到類似的速率。
那麼，我能走多遠（最新版本的）Windows / Windows Server，特別是接收開頭段落中描述的 UDP 多播？
編輯有一篇 cloudflare 部落格文章 - 以及一個有趣的評論部分 - 關於如何在 Linux 上執行此操作：如何每秒接收一百萬個資料包，還有對應的駭客新聞評論頁面。
答案1
據微軟稱，在他們的實驗室進行了測試顯示“在早期測試中的特定伺服器上”裡歐，他們能夠處理
- 2Mpps無損耗在 Windows 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 資料。
編輯我剛剛偶然發現了一份英特爾文檔高效能資料包處理在 Linux 上，據此，(Linux)
平台可維持每秒約200萬筆交易的交易率
使用標準 Linux 網路堆疊（在具有 2x8 核心的實體主機上）。此請求/回覆測試中的事務包括
- 接收UDP封包
- 該資料包的後續轉發
（使用netperf的網路伺服器）。該測試並行運行 100 個交易。對於有興趣的人來說，本文中有更多詳細資訊。我希望我們有這樣的 Windows 來進行比較...無論如何，這是與該請求/回復測試最相關的圖表：
答案2
太長了；博士
為了給出明確的答案，似乎需要更多的測驗。但間接證據表明 Linux 是實際上專門用於超低延遲社群的作業系統，它也經常處理 Mpps 工作負載。這並不意味著 Windows 不可能做到這一點，但 Windows 可能會落後相當多，儘管有可能達到 Mpps 數字。但這需要透過測試來確定，例如弄清楚需要多少（CPU）成本才能實現這些數字。
注意這不是我打算接受的答案。它的目的是為任何對這個問題的答案感興趣的人提供一些關於我們的立場以及進一步調查的地方的提示。
據 google 稱，Len Holgate 似乎是唯一一個測試 RIO 以從 Windows 網路中獲得更多效能的人（並發布了結果），他剛剛在一份聲明中進行了澄清。在他的部落格上發表評論他使用單一 IP/連接埠組合來發送 UDP 封包。
換句話說，他的結果應該與 Linux 上測試中的單核心資料有些相似（儘管他使用了8 個線程- 在尚未檢查他的程式碼的情況下，在僅處理單個UDP 資料包流並且不對資料包進行任何繁重處理時，這似乎對效能有害，而且他提到實際只使用了很少的線程，這是有道理的）。儘管他說：
我並沒有那麼努力地獲得最大效能，只是為了比較新舊 API 之間的相對效能，因此我的測試並沒有那麼徹底。
但什麼是放棄標準 IOCP 的（相對）舒適區，進入更粗糙的 RIO 世界除了「努力」之外？至少就單一 UDP 封包流而言是如此。
我猜他的意思是——正如他在幾次 RIO 測試中嘗試了各種設計方法一樣——他沒有微調 NIC 設定來擠出最後一點性能。例如，在以下情況下接收緩衝區大小可能會對 UDP 接收效能和資料包遺失資料產生巨大的正面影響。
然而，當嘗試直接將他的結果與其他Linux/Unix/BSD 測試的結果進行比較時，問題是：大多數測試在嘗試推動「每秒資料包」邊界時，使用盡可能小的資料包/幀大小，即乙太網路64位元組的幀。 Len 測試了1024 位元組資料包（-> 1070 位元組幀），這（特別是對於No-Nagle UDP）可以讓您獲得更高的「每秒位元數」數字，但可能無法像較小的數據包那樣推動pps 邊界。因此，按原樣比較這些數字是不公平的。
總結到目前為止我對 Windows UDP 接收效能的探索結果：
- 在嘗試開發超低延遲和/或高吞吐量應用程式時，沒有人真正使用 Windows，現在他們正在使用 Linux
- 現在幾乎所有帶有實際結果的效能測試和報告（即不僅僅是產品廣告）都是在 Linux 或 BSD 上進行的（感謝 Len 作為先驅，給我們至少提供了一個參考點！）
- Windows 上的 UDP（標準套接字）比 Linux 快/慢嗎？我還不能確定，必須自己測試
- Windows 上的高效能 UDP（RIO 與 netmap）比 Linux 上更快/更慢嗎？ Linux容易地使用 900MHz 的單核心處理全 10Gb 線路速度，Windows，最佳案例已發布對於 1024 的大 UDP 封包大小，能夠達到 43% 或 492kpps，即較小大小的 bps 數字可能會明顯更差，儘管 pps 數字可能會上升（除非中斷處理或其他一些核心空間開銷是限制因素）。
至於他們為什麼使用Linux，那一定是因為開發涉及核心變更（如netmap 或RIO）的解決方案（將效能推向極限時所必需的）對於像Windows 這樣的封閉系統來說幾乎是不可能的，除非你的薪水恰好來自雷蒙德，或者您與 Microsoft 簽訂了一些特殊合約。這就是為什麼 RIO 是 MS 產品。
最後，舉幾個極端的例子來說明我在 Linux 領域曾經和正在發生的事情：
早在 15 年前，有些人就已經使用800 mHz Pentium III CPU，133 mHz 前端匯流排在 1GbE NIC 上。 編輯: 他們用的是點選，一個繞過大部分標準網路堆疊的核心模式路由器，即它們「作弊」。
2013年，氬設計管理要得到
勾選交易延遲低至 35ns [奈秒]
順便說一句，他們還聲稱
和氬氣使用Arista 7124FX 交換機，（除了 FPGA 之外）還有一個作業系統
建構在標準 Linux 核心之上。