Ist es möglich, mit Windows Millionen von Datagrammen pro Sekunde zu verarbeiten?

Ich untersuche, ob ich eine HPC-App unter Windows implementieren kann, die kleine UDP-Multicast-Datagramme (meistens 100-400 Byte) mit einer hohen Rate empfängt, wobei ich ein Dutzend oder bis zu 200 Multicast-Gruppen verwende (dh MSI-X und RSS kann ich auf mehrere Kerne skalieren), verarbeitet etwas pro Paket und sendet es dann aus. Beim Senden über TCP gelang es mir, so weit wie nötig zu steigen (6,4 Gbit / s), ohne gegen eine Wand zu stoßen, aber das Empfangen von Datagrammen mit hohen pps-Raten stellte sich als Problem heraus.

In einem kürzlich durchgeführten Test auf einem hochspezifizierten NUMA-Computer mit einer 10-Gbit-Ethernet-Netzwerkkarte mit 2 Ports unter Windows 2012 R2 konnte ich nur Hunderttausende von UDP-Datagrammen pro Sekunde empfangen (Early Drop, dh ohne die Daten tatsächlich zu verarbeiten) Entfernen Sie den Verarbeitungsaufwand meiner App aus der Gleichung, um zu sehen, wie schnell sie wird, indem Sie 2x12 Kerne verwenden, und der Kernel-Teil der 12 getesteten Multicast-Gruppen schien auf 8 oder 10 Kerne eines NUMA-Knotens verteilt zu sein ( Max. RSS-Warteschlangen wurden festgelegt bis 16) - allerdings mit einer .net-App, sodass native Apps schneller arbeiten können sollten.

Aber selbst Len Holgate konnte in seinen Hochleistungs-Windows-RIO-Tests mit einer UDP-Nutzlast von 1024 Byte nur UDP-Pakete mit 500 kpps empfangen .

Im Whitepaper von QLogic (Betriebssystem im Test nicht erwähnt) sind die Grenzwerte für das "Routing von Multithread-Paketen mit mehreren Threads" (also sowohl das Empfangen als auch das anschließende Senden?) Auf 5,7 MPs festgelegt . In Artikeln über Linux-Netzwerke werden die Grenzwerte auf 1 Mpps bis 2 Mpps pro Kern festgelegt (angeblich mehr oder weniger linear skaliert) oder sogar auf 15 Mpps mit speziellen Lösungen, die den Kernel umgehen.

ZB Netmap

kann Datenverkehr mit einer Leitungsrate ( 14,88 Mpps ) auf einer 10GigE-Verbindung mit nur einem einzigen Kern erzeugen, der mit 900 Mhz ausgeführt wird. Dies entspricht etwa 60 bis 65 Taktzyklen pro Paket und lässt sich gut mit Kernen und Taktfrequenz skalieren (mit 4 Kernen wird eine Leitungsrate von weniger als 450 MHz erreicht). Ähnliche Preise werden auf der Empfangsseite erreicht .

Wie weit kann ich (die neuesten Versionen von) Windows / Windows Server bringen, insbesondere UDP-Multicast empfangen, wie im ersten Absatz beschrieben?

Bearbeiten Es gibt einen Cloudflare-Blog-Beitrag - und einen interessanten Kommentarbereich - darüber, wie es unter Linux geht: Wie man eine Million Pakete pro Sekunde empfängt , und es gibt die entsprechende Seite mit Hacker-News-Kommentaren .

Laut Microsoft haben Tests in ihrem Labor gezeigt, dass sie "auf einem bestimmten Server in frühen Tests" von RIO handhaben konnten

• 2Mpps ohne Verlust in Windows Server 2008R2, dh ohne RIO
• 4Mpps unter (Vorabversion) Windows Server 8 mit RIO

Screenshot von diesem Video (44:33):

Die Antwort auf meine Frage Is it possible to process millions of datagrams per second with Windows?wäre also: Ja , und anscheinend war es sogar vor RIO in Windows Server 2008R2.

Zusätzlich zu den offiziellen Zahlen, insbesondere zu unveröffentlichter Software, die mit einer Prise Salz eingenommen werden müssen und nur die spärlichen Informationen in dieser Präsentation enthalten, bleiben jedoch viele Fragen zum Test und damit zur richtigen Interpretation der Ergebnisse offen. Die wichtigsten sind:

1. Sind die Zahlen für das Senden? Empfang? Oder vielleicht für das Routing (dh Empfangen + Senden)?
2. Welche Paketgröße? -> Wahrscheinlich das niedrigstmögliche, wie es normalerweise getan wird, wenn versucht wird, pps-Zahlen zum Prahlen zu bringen
3. Wie viele Verbindungen (wenn TCP) / Paketströme (wenn UDP) ? -> Wahrscheinlich so viele wie nötig, um die Arbeitslast zu verteilen, damit alle vorhandenen Kerne verwendet werden können
4. Welcher Testaufbau? Maschinen- und NIC-Spezifikationen und Verkabelung

Der erste ist entscheidend, da Senden und Empfangen unterschiedliche Schritte erfordern und erhebliche Leistungsunterschiede aufweisen können. Für die anderen Figuren können wir wahrscheinlich annehmen, dass die niedrigste Paketgröße mit mindestens einer Verbindung / einem Paketstrom pro Kern auf einer hochspezifizierten Maschine verwendet wurde, um die maximal möglichen Mpps-Zahlen zu erhalten.

Bearbeiten Ich bin gerade auf ein Intel-Dokument über die Verarbeitung von Hochleistungspaketen unter Linux gestoßen , und dementsprechend ist das (Linux)

Die Plattform kann eine Transaktionsrate von etwa 2 Millionen Transaktionen pro Sekunde aufrechterhalten

Verwenden des Standard-Linux-Netzwerkstapels (auf einem physischen Host mit 2x8-Kernen). Eine Transaktion in diesem Anforderungs- / Antworttest umfasst beide

1. Empfang eines UDP-Pakets
2. anschließende Weiterleitung dieses Pakets

(mit dem Netserver von netperf). Der Test führte 100 Transaktionen parallel aus. Es gibt viele weitere Details in der Zeitung für Interessierte. Ich wünschte, wir hätten so etwas für Windows zum Vergleichen ... Wie auch immer, hier ist das relevanteste Diagramm für diesen Anfrage- / Antworttest:

tl; dr

Um eine eindeutige Antwort zu geben, scheinen weitere Tests erforderlich zu sein. Indizien deuten jedoch darauf hin, dass Linux das Betriebssystem ist, das praktisch ausschließlich in der Community mit extrem geringer Latenz verwendet wird, die auch routinemäßig Mpps-Workloads verarbeitet. Das bedeutet nicht, dass es mit Windows unmöglich ist, aber Windows wird wahrscheinlich einiges hinterherhinken, obwohl es möglicherweise möglich ist, Mpps-Zahlen zu erreichen. Dazu müssen jedoch Tests durchgeführt werden, um beispielsweise herauszufinden, zu welchen (CPU-) Kosten diese Zahlen erreicht werden können.

NB Dies ist keine Antwort, die ich akzeptieren möchte. Es ist beabsichtigt, jedem, der an einer Antwort auf die Frage interessiert ist, einige Hinweise zu geben, wo wir stehen und wo wir weitere Untersuchungen durchführen können.

Len Holgate, der laut Google der einzige zu sein scheint, der RIO getestet hat, um mehr Leistung aus Windows-Netzwerken herauszuholen (und die Ergebnisse veröffentlicht hat), hat gerade in einem Kommentar in seinem Blog klargestellt, dass er eine einzige IP / Port-Kombination verwendet zum Senden der UDP-Pakete.

Mit anderen Worten, seine Ergebnisse sollten in gewisser Weise mit den Single-Core-Zahlen in Tests unter Linux vergleichbar sein (obwohl er 8 Threads verwendet - was, ohne seinen Code noch überprüft zu haben, die Leistung beeinträchtigt, wenn nur ein einziger UDP-Paketstrom verarbeitet wird und nicht Er erwähnt, dass nur wenige Threads tatsächlich verwendet werden, was Sinn machen würde. Das ist, obwohl er sagt:

Ich habe mich nicht so sehr bemüht, maximale Leistung zu erzielen, nur um die relative Leistung zwischen alten und neuen APIs zu vergleichen, und deshalb war ich bei meinen Tests nicht so gründlich.

Aber was gibt die (relative) Komfortzone des Standard-IOCP für die rauere RIO-Welt auf, außer "hart zu versuchen"? Zumindest was einen einzelnen UDP-Paketstrom betrifft.

Ich denke, was er meint - da er in mehreren RIO-Tests verschiedene Designansätze ausprobiert hat - ist, dass er zB die NIC-Einstellungen nicht fein abgestimmt hat, um das letzte Stück Leistung herauszuholen. Dies kann sich beispielsweise im Fall der Empfangspuffergröße möglicherweise erheblich positiv auf die UDP-Empfangsleistung und die Paketverlustzahlen auswirken.

Das Problem beim Versuch, seine Ergebnisse direkt mit denen anderer Linux / Unix / BSD-Tests zu vergleichen, ist jedoch folgendes: Die meisten Tests verwenden beim Versuch, die Grenze "Pakete pro Sekunde" zu verschieben, die kleinstmögliche Paket- / Rahmengröße, dh ein Ethernet Rahmen von 64 Bytes. Len testete 1024-Byte-Pakete (-> einen 1070-Byte-Frame), wodurch (insbesondere für No-Nagle-UDP) viel höhere "Bits pro Sekunde" -Zahlen erzielt werden können, die pps-Grenze jedoch möglicherweise nicht so weit verschoben wird, wie dies bei kleineren Paketen möglich ist . Es wäre also nicht fair, diese Zahlen so zu vergleichen, wie sie sind.

Das Zusammenfassen der Ergebnisse meiner Suche in Windows UDP erhält bisher Leistung:

• Niemand verwendet Windows wirklich, wenn er versucht, Anwendungen mit extrem geringer Latenz und / oder hohem Durchsatz zu entwickeln. Heutzutage verwenden sie Linux
• Praktisch alle Leistungstests und Berichte mit tatsächlichen Ergebnissen (dh nicht nur Produktwerbung) finden heutzutage unter Linux oder BSD statt (danke Len, dass er ein Pionier ist und uns mindestens einen Bezugspunkt gibt!)
• Ist UDP (Standard Sockets) unter Windows schneller / langsamer als unter Linux? Ich kann es noch nicht sagen, müsste meine eigenen Tests machen
• Ist Hochleistungs-UDP (RIO vs Netmap) unter Windows schneller / langsamer als unter Linux? Linux verarbeitet problemlos die volle 10-Gbit-Leitungsgeschwindigkeit mit einem einzigen Kern bei 900 MHz. Windows kann im besten Fall bei einer großen UDP-Paketgröße von 1024 bis zu 43% oder 492 kpps erreichen, dh die BPS-Werte für kleinere Größen werden wahrscheinlich erheblich sein Schlimmer, obwohl die pps-Zahlen wahrscheinlich steigen werden (es sei denn, die Interrupt-Behandlung oder ein anderer Kernel-Speicher-Overhead ist der begrenzende Faktor).

Der Grund, warum sie Linux verwenden, muss daran liegen, dass die Entwicklung von Lösungen mit Kerneländerungen wie Netmap oder RIO - die erforderlich sind, um die Leistung an ihre Grenzen zu bringen - mit einem geschlossenen System wie Windows nahezu unmöglich ist, es sei denn, Ihre Gehaltsschecks stammen zufällig aus Redmond. oder Sie haben einen Sondervertrag mit Microsoft. Deshalb ist RIO ein MS-Produkt.

Um nur einige extreme Beispiele dafür zu nennen, was ich im Linux-Land entdeckt habe und was gerade passiert:

Bereits vor 15 Jahren erhielten einige 680 kpps mit einer 800-MHz-Pentium III-CPU und einem 133-MHz-Front-Side-Bus auf einer 1-GbE-Netzwerkkarte. Bearbeiten : Sie verwendeten Click , einen Router im Kernel-Modus, der einen Großteil des Standard-Netzwerkstapels umgeht, dh sie "betrogen" haben.

Im Jahr 2013 Argon Entwurf verwaltet zu bekommen

kreuzen Sie an, um Latenzen von nur 35 ns [Nanosekunden] zu tauschen.

Übrigens behaupten sie das auch

Die überwiegende Mehrheit des heute für den Handel vorhandenen Computercodes ist für Linux auf x86-Prozessorarchitekturen geschrieben.

und Argon verwenden den Arista 7124FX-Switch , der (zusätzlich zu einem FPGA) über ein Betriebssystem verfügt

Aufbauend auf einem Standard-Linux-Kernel.

Sie müssen sicherlich verschiedene Konfigurationen und Szenarien "messen". Dies kann AFAIK mit zwei Geräten von 2 Unternehmen durchgeführt werden. IXIA und Spirent . Sie bieten hardwarebasierte Verkehrsgeneratoren, die den Verkehr mit Leitungsgeschwindigkeit pumpen können. Sie bieten einen Rampentest, bei dem Sie die Geschwindigkeit ermitteln können, mit der Ihr bestimmtes System zusammenbrechen könnte. Die Geräte sind teuer, aber Sie können sie mieten.