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 .
quelle
Antworten:
Laut Microsoft haben Tests in ihrem Labor gezeigt, dass sie "auf einem bestimmten Server in frühen Tests" von RIO handhaben konnten
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:
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)
Verwenden des Standard-Linux-Netzwerkstapels (auf einem physischen Host mit 2x8-Kernen). Eine Transaktion in diesem Anforderungs- / Antworttest umfasst beide
(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:
quelle
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:
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:
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
Übrigens behaupten sie das auch
und Argon verwenden den Arista 7124FX-Switch , der (zusätzlich zu einem FPGA) über ein Betriebssystem verfügt
quelle
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.
quelle