Ich untersuche, ob ich eine HPC-Anwendung unter Windows implementieren kann, dieempfängt kleine UDP-Multicast-Datagramme (meist 100-400 Bytes) mit hoher Geschwindigkeit und verwendet dabei ein Dutzend oder bis zu 200 Multicast-Gruppen(d. h. mit MSI-X und RSS kann ich auf mehrere Kerne skalieren), führt einige Verarbeitungen pro Paket durch und sendet es dann aus. Beim Senden über TCP konnte ich die erforderliche Geschwindigkeit erreichen (6,4 Gb/s), ohne an ein Ende zu stoßen, aber der Empfang von Datagrammen mit hohen PPS-Raten erwies sich als Problem.
In einemletzter TestAuf einer High-Spec-NUMA-Maschine mit einer 2-Port 10Gb Ethernet-NIC unter Windows 2012 R2 konnte ich nurHunderttausende UDP-Datagramme pro Sekunde empfangen(Early Drop, d. h. ohne tatsächliche Verarbeitung der Daten, um den Verarbeitungsaufwand meiner App aus der Gleichung zu entfernen und zu sehen, wie schnell sie wird) mit 2 x 12 Kernen, und der Kernel-Teil der 12 getesteten Multicast-Gruppen schien auf 8 oder 10 Kerne eines NUMA-Knotens verteilt zu sein (Max. RSS-Warteschlangenwurde auf 16 eingestellt) – allerdings mit einer .net-App, native Apps sollten also schneller laufen können.
Aber selbstLen Holgate konnte nur UDP-Pakete mit 500 kpps empfangenInseine hochleistungsfähigen Windows RIO-Tests, unter Verwendung einer UDP-Nutzlast von 1024 Bytes.
InDas Whitepaper von QLogic(Das zu testende Betriebssystem wird nicht erwähnt) Die Grenzwerte für das „multithreaded super-small packet routing“ (umfasst das also sowohl den Empfang als auch das nachfolgende Senden?) sind auf5,7 Mpps. InArtikelAnLinux-NetzwerkDie Grenzwerte liegen bei1 Mpps bis 2 Mppspro Kern (angeblich mehr oder weniger linear skalierend) oder sogar15 Mppsmit speziellen Lösungen, die den Kernel umgehen.
Z.BNetzkarte
kann Verkehr mit Leitungsgeschwindigkeit erzeugen (14,88 Mpps) auf einer 10GigE-Verbindung mit nur einem Kern, der mit 900 MHz läuft. Dies entspricht etwa 60-65 Taktzyklen pro Paket und skaliert gut mit Kernen und Taktfrequenz (mit 4 Kernen wird eine Leitungsgeschwindigkeit von weniger als 450 MHz erreicht).Ähnliche Raten werden auf der Empfängerseite erreicht.
Wie weit kann ich also (mit den neuesten Versionen von) Windows/Windows Server kommen, insbesondere beim Empfang von UDP-Multicast, wie im einleitenden Absatz beschrieben?
BearbeitenEs gibt einen Cloudflare-Blogbeitrag – und einen interessanten Kommentarbereich – dazu, wie das unter Linux funktioniert:So empfangen Sie eine Million Pakete pro Sekunde, und es gibt die entsprechendeHacker-News-Kommentarseite.
Antwort1
Laut Microsoft haben Tests in ihrem Laborzeigtedass "auf einem bestimmten Server in frühen Tests" vonRIOwaren sie in der Lage,
- 2 Mpps ohne Verlustin Windows Server 2008R2, also ohne RIO
- 4 Mpps auf (Vorabversion) Windows Server 8 mit RIO
Screenshot aus diesem Video (44:33):
Also die Antwort auf meine FrageIs it possible to process millions of datagrams per second with Windows?wäre:Ja, und anscheinend war dies sogar schon vor RIO der Fall, nämlich in Windows Server 2008R2.
Aber abgesehen davon, dass offizielle Zahlen, insbesondere zu noch unveröffentlichter Software, mit Vorsicht zu genießen sind und nur spärliche Informationen in dieser Präsentation gegeben werden, bleiben viele Fragen zum Test und damit zur richtigen Interpretation der Ergebnisse offen. Die wichtigsten davon sind:
- Sind die Zahlen für das Senden? Empfangen?Oder vielleicht für das Routing (also Empfangen + Senden)?
- Welche Paketgröße?-> Wahrscheinlich der niedrigste Wert, wie er normalerweise verwendet wird, wenn man mit PPS-Zahlen angeben will
- Wie viele Verbindungen (bei TCP) / Paketströme (bei UDP)? -> Wahrscheinlich so viele wie nötig, um die Arbeitslast so zu verteilen, dass alle vorhandenen Kerne genutzt werden können
- Welcher Testaufbau?Maschinen- und NIC-Spezifikationen und Verkabelung
Der erste Wert ist entscheidend, da Senden und Empfangen unterschiedliche Schritte erfordern und erhebliche Leistungsunterschiede aufweisen können. Bei den anderen Werten können wir wahrscheinlich davon ausgehen, dass die niedrigste Paketgröße mit mindestens einer Verbindung/einem Paketstrom pro Kern auf einer Hochleistungsmaschine verwendet wurde, um die maximal möglichen Mpps-Werte zu erreichen.
BearbeitenIch bin gerade über ein Intel-Dokument gestolpert, in dem es umLeistungsstarke Paketverarbeitungauf Linux, und dementsprechend ist das (Linux)
Plattform kann eine Transaktionsrate von etwa 2 Millionen Transaktionen pro Sekunde aufrechterhalten
unter Verwendung des Standard-Linux-Netzwerk-Stacks (auf einem physischen Host mit 2x8 Kernen). Eine Transaktion in diesem Anfrage-/Antwort-Test umfasst sowohl
- Empfang eines UDP-Pakets
- anschließende Weiterleitung dieses Pakets
(unter Verwendung des Netservers von netperf). Der Test führte 100 Transaktionen parallel aus. Für Interessierte gibt es im Dokument noch viele weitere Einzelheiten. Ich wünschte, wir hätten so etwas zum Vergleichen für Windows ... Wie dem auch sei, hier ist das relevanteste Diagramm für diesen Anfrage-/Antworttest:
Antwort2
tl;dr
Um eine eindeutige Antwort zu geben, scheinen weitere Tests notwendig zu sein. Indizien deuten jedoch darauf hin, dass Linux das Betriebssystem ist, das praktisch ausschließlich in der Ultra-Low-Latency-Community verwendet wird, die auch routinemäßig Mpps-Workloads verarbeitet. Das heißt nicht, dass dies mit Windows unmöglich ist, aber Windows wird wahrscheinlich ziemlich weit zurückliegen, obwohl es möglich sein könnte, Mpps-Zahlen zu erreichen. Dies muss jedoch durch Tests sichergestellt werden, und z. B. um herauszufinden, zu welchen (CPU-)Kosten diese Zahlen erreicht werden können.
NB: Dies ist keine Antwort, die ich akzeptieren werde. Sie soll jedem, der an einer Antwort auf die Frage interessiert ist, einige Hinweise darauf geben, wo wir stehen und wo weitere Nachforschungen angestellt werden sollten.
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 einemKommentiere seinen Blogdass er eine einzelne IP/Port-Kombination zum Senden der UDP-Pakete verwendete.
Mit anderen Worten, seineDie Ergebnisse sollten einigermaßen mit den Single-Core-Werten bei Tests unter Linux vergleichbar sein.(obwohl er 8 Threads verwendet – was, ohne dass ich seinen Code bisher überprüft habe, der Leistung abträglich zu sein scheint, wenn nur ein einziger UDP-Paketstrom verarbeitet wird und keine umfangreiche Verarbeitung der Pakete erfolgt, und er erwähnt, dass tatsächlich nur wenige Threads verwendet werden, was Sinn ergeben würde). Und das, obwohl er sagt:
Ich habe nicht so sehr versucht, die maximale Leistung herauszuholen, sondern nur die relative Leistung zwischen alten und neuen APIs zu vergleichen und war daher bei meinen Tests nicht so gründlich.
Aber was istAufgeben der (relativen) Komfortzone des Standard-IOCP zugunsten der raueren RIO-Weltaußer sich „anstrengen“? Zumindest soweit es einen einzelnen UDP-Paketstrom betrifft.
Ich vermute, was er meint - da er in mehreren Tests von RIO verschiedene Designansätze ausprobiert hat - ist, dass er beispielsweise die NIC-Einstellungen nicht feinabgestimmt hat, um das letzte bisschen Leistung herauszuholen. Was beispielsweise im Fall vonGröße des Empfangspufferskönnte möglicherweise einen enorm positiven Einfluss auf die UDP-Empfangsleistung und die Paketverlustzahlen haben.
Das Problem beim direkten Vergleich seiner Ergebnisse mit denen anderer Linux/Unix/BSD-Tests ist jedoch folgendes: Die meisten Tests verwenden beim Versuch, die Grenze der „Pakete pro Sekunde“ zu überschreiten, die kleinstmögliche Paket-/Framegröße, also einen Ethernet-Frame von 64 Bytes. Len testete 1024-Byte-Pakete (-> einen 1070-Byte-Frame), die (insbesondere für No-Nagle UDP) zu viel höheren „Bits pro Sekunde“-Werten führen können, die PPS-Grenze jedoch möglicherweise nicht so weit verschieben, wie dies bei kleineren Paketen der Fall wäre. Daher wäre es nicht fair, diese Werte so zu vergleichen, wie sie sind.
Zusammenfassung der Ergebnisse meiner bisherigen Untersuchung zur UDP-Empfangsleistung von Windows:
- Niemand verwendet wirklich Windows, wenn er versucht, Anwendungen mit extrem niedriger Latenz und/oder hohem Durchsatz zu entwickeln, heutzutage verwenden sie Linux
- Heutzutage werden praktisch alle Leistungstests und Berichte mit tatsächlichen Ergebnissen (also nicht bloße Produktwerbung) auf Linux oder BSD durchgeführt (danke, Len, dass du ein Pionier bist und uns zumindest einen Bezugspunkt gibst!)
- Ist UDP (Standard-Sockets) unter Windows schneller/langsamer als unter Linux? Das kann ich noch nicht sagen, ich müsste es selbst testen.
- Ist High-Performance-UDP (RIO vs. Netmap) unter Windows schneller/langsamer als unter Linux? Linuxleichtverarbeitet volle 10Gb Leitungsgeschwindigkeit mit einem einzigen Kern bei 900MHz, Windows, in derbester Fall veröffentlichtkann bei einer großen UDP-Paketgröße von 1024 auf bis zu 43 % oder 492 kpps steigen, d. h. die bps-Werte für kleinere Größen werden wahrscheinlich erheblich schlechter sein, obwohl die pps-Werte wahrscheinlich steigen werden (es sei denn, die Interrupt-Verarbeitung oder ein anderer Kernel-Speicherplatz-Overhead ist der begrenzende Faktor).
Der Grund, warum sie Linux verwenden, liegt wahrscheinlich darin, dass die Entwicklung von Lösungen, die Kerneländerungen wie Netmap oder RIO erfordern - die notwendig sind, um die Leistung bis an die Grenzen zu treiben - mit einem geschlossenen System wie Windows nahezu unmöglich ist, es sei denn, Ihr Gehalt kommt zufällig aus Redmond oder Sie haben einen speziellen Vertrag mit Microsoft. Deshalb ist RIO ein MS-Produkt.
Zum Schluss noch ein paar extreme Beispiele für die Vorgänge im Linux-Bereich:
Schon vor 15 Jahren empfingen einige 680kpps mit einem800 MHz Pentium III CPU, 133 MHz Frontside-Busauf einer 1GbE-Netzwerkkarte. Bearbeiten: Sie benutztenKlicken, ein Kernel-Modus-Router, der einen Großteil des Standard-Netzwerkstapels umgeht, d. h. sie haben „geschummelt“.
Im Jahr 2013 hat Argon Designgelang eszu bekommen
Tick-to-Trade-Latenzen von nur 35 ns [Nanosekunden]
Übrigens behaupten sie auch, dass
und Argon verwenden dieArista 7124FX-Schalter, das (zusätzlich zu einem FPGA) ein Betriebssystem hat
auf einem Standard-Linux-Kernel aufgebaut.
Antwort3
Sie müssen sicherlich verschiedene Konfigurationen und Szenarien „messen“. Dies kann meines Wissens nach mit zwei Geräten von zwei Unternehmen durchgeführt werden.IXIAUndSpirent. Sie bieten hardwarebasierte Verkehrsgeneratoren an, die den Verkehr mit Leitungsgeschwindigkeit pumpen können. Sie bieten Rampentests an, mit denen Sie die Geschwindigkeit ermitteln können, bei der Ihr spezielles System zusammenbrechen könnte. Die Geräte sind teuer, aber Sie können sie mieten.