🤖 AI

OpenURMA: A Clean-Room Open Implementation of the Unified Bus Protocol

Dieser Beitrag stellt OpenURMA vor, die erste Clean-Room-Open-Source-Implementierung des Unified-Bus-Protokolls von Huawei, die durch RTL-, SystemC- und gem5-Simulationen nachweist, dass die Entkopplung des pro-Anwendung zustands vom Transportzustand die Latenz bei Remote-Fetchs von 64 Bytes im Vergleich zu herkömmlichen RoCEv2-Baselines um den Faktor 4,37 reduziert und den Durchsatz um den Faktor 2,80 steigert.

Ursprüngliche Autoren: Bojie Li

Veröffentlicht 2026-05-28

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Bojie Li

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Das große Problem: Der „Peripherie"-Flaschenhals

Stellen Sie sich ein modernes Rechenzentrum als ein riesiges Bürogebäude vor, in dem Tausende von Mitarbeitern (Anwendungen) sofort miteinander kommunizieren müssen.

Derzeit läuft die Standardkommunikation so ab:

Das Peripherie-Problem: Die Netzwerkkarte (NIC) wird wie ein Peripheriegerät behandelt, ähnlich einem Drucker oder einer Maus, die an einen Computer angeschlossen sind. Sie sitzt „außerhalb" des Hauptgehirns (der CPU).
Das Warteschlangensystem: Um eine Nachricht zu senden, muss ein Mitarbeiter einen Zettel (eine „Work Request") schreiben, ihn zum Briefkasten der Netzwerkkarte (der „Doorbell") bringen und warten. Die Netzwerkkarte nimmt ihn dann auf, verarbeitet ihn und schreibt einen „Erledigt"-Zettel zurück in den Briefkasten.
Der Stau: Da die Netzwerkkarte „außerhalb" ist, muss jeder einzelne Zettel viermal eine belebte Autobahn (den PCIe-Bus) überqueren, nur um gesendet und bestätigt zu werden.
Die Speicherkrise: Die Netzwerkkarte muss für jedes einzelne Paar von Mitarbeitern, die miteinander sprechen, einen persönlichen Ordner führen. Wenn Sie 1.000 Mitarbeiter haben, die mit jeweils 1.000 anderen sprechen, benötigt die Karte 1 Million Ordner. Der Schreibtischplatz (On-Chip-Speicher) wird knapp, und sie muss beginnen, zum Aktenschrank im Keller (Host-RAM) zu rennen, um Dateien zu holen. Dies verlangsamt alles ins Schleudern.

Das Ergebnis: Obwohl die Internetkabel (das „Kabel") unglaublich schnell sind, steckt das gesamte System im Stau fest, weil die Netzwerkkarte so verbunden und organisiert ist.

Die Lösung: Huaweis Unified Bus (UB)

Huawei schlug ein neues Design namens Unified Bus (UB) (in ihrem Ascend 950-Chip) vor, um dies zu beheben. Sie haben das alte System nicht nur geflickt; sie haben die Verkehrsregeln geändert.

1. Das Büro ins Gebäude verlegen
Anstatt dass die Netzwerkkarte ein Peripheriegerät außerhalb des Gebäudes ist, platziert UB den Netzwerkkontroller innerhalb des Gebäudes im Haupthof (dem On-Chip-Bus).

Analogie: Anstatt zum Foyer zu laufen, um einen Brief aufzugeben, können Sie ihn nun einfach einem Kollegen übergeben, der direkt neben Ihrem Schreibtisch steht. Sie müssen die Autobahn nicht viermal überqueren; Sie machen nur einen Schritt.

2. Das Ablagesystem aufteilen
Das alte System führte für jedes sprechende Personenpaar einen riesigen Ordner. UB teilt dies auf:

Jetty: Eine kleine Karte für Ihre Seite des Gesprächs.
TP-Kanal: Eine gemeinsame Karte für die Seite der anderen Person.
Analogie: Anstatt einen einzigartigen Ordner für jedes Personenpaar zu benötigen (was die Größe explodieren lässt), benötigen Sie nur eine Karte für sich selbst und eine gemeinsame Karte für die Person, mit der Sie sprechen. Die Gesamtzahl der Ordner wächst langsam (additiv) statt zu explodieren (multiplikativ). Dies verhindert, dass der Schreibtischplatz der Netzwerkkarte überläuft.

3. Die „Load/Store"-Abkürzung
Da der Controller nun im Gebäude ist, kann die CPU direkt mit Standardbefehlen (wie LOAD oder STORE) mit ihm sprechen, genau wie beim Lesen einer Variablen in einem Programm.

Analogie: Sie müssen kein Formular ausfüllen, zum Briefkasten laufen und auf eine Quittung warten. Sie greifen einfach sofort auf die benötigten Daten zu.

4. Optionale Regeln (Opt-in-Reihenfolge)
Das alte System zwang strikte Regeln auf: „Sie müssen Nachrichten genau in der Reihenfolge empfangen, in der sie gesendet wurden, egal was passiert." Dies ist langsam und für viele Aufgaben unnötig.

Analogie: UB sagt: „Wir können Nachrichten so schnell wie möglich liefern. Wenn Sie sie wirklich in der Reihenfolge benötigen, heben Sie einfach die Hand, und wir verlangsamen uns, um sie zu sortieren. Wenn es Ihnen egal ist, werfen wir sie einfach so, wie sie ankommen, in Ihren Posteingang." Dies spart Zeit für alle, die keine strikte Reihenfolge benötigen.

Was OpenURMA getan hat

Huaweis Chip existiert, ist aber eine „Blackbox". Niemand kann sehen, wie er im Inneren funktioniert, ihn messen oder darauf aufbauen.

OpenURMA ist die erste Open-Source-Clean-Room-Implementierung dieses neuen Systems.

„Clean-Room" bedeutet, dass sie es von Grund auf neu bauten, ausschließlich unter Verwendung des öffentlichen Regelwerks (der Spezifikation), ohne Huaweis geheimen Code zu betrachten.
Sie bauten drei Versionen, um es zu testen:
1. RTL: Der eigentliche Bauplan für Hardware-Chips (getestet auf einer FPGA-Platine).
2. SystemC: Eine extrem detaillierte Computersimulation des Netzwerks.
3. gem5: Eine vollständige Computersimulation, die ein echtes Betriebssystem ausführt.

Sie verglichen ihr neues System (OpenURMA) mit dem alten Standard (RoCEv2) unter Verwendung exakt derselben Werkzeuge, um einen fairen Vergleich zu gewährleisten.

Die Ergebnisse: Wie viel schneller?

Das Papier behauptet massive Verbesserungen, insbesondere für kleine, schnelle Operationen (wie das Abrufen eines winzigen Datenstücks):

Geschwindigkeit: Das neue System ist für einen Standard-Datenabruf 4,37-mal schneller (etwa 500 Nanosekunden) als das alte System (etwa 2.186 Nanosekunden).
Durchsatz: Es kann 2,8-mal mehr Daten pro Sekunde verarbeiten.
Effizienz: Es benötigt sehr wenig Platz auf dem Chip (nur etwa 14 % des verfügbaren Platzes auf einer Testplatine).
Skalierbarkeit: Wenn Sie mehr Benutzer hinzufügen (von 1 auf 1.024), verlangsamt sich das alte System drastisch, weil der Schreibtischplatz ausgeht. Das neue System bleibt schnell und stabil, weil sein Ablagesystem effizient ist.

Warum das wichtig ist (laut dem Papier)

Das Papier argumentiert, dass die derzeitige Art, wie wir Computer in Rechenzentren verbinden (indem wir die Netzwerkkarte als Peripheriegerät behandeln), für moderne KI- und Big-Data-Arbeitslasten fundamental defekt ist.

Die „kohärente" Alternative: Es gibt andere Technologien (wie CXL oder NVLink), die versuchen, Speicher „geteilt" und „kohärent" erscheinen zu lassen. Das Papier argumentiert jedoch, dass diese Technologien zusammenbrechen, wenn man versucht, sie auf große Cluster (viele Server-Racks) hochzuskalieren, da sie zu viel Zustandsverfolgung erfordern und Netzwerklefehler nicht gut bewältigen können.
Der UB-Vorteil: UB akzeptiert, dass das Netzwerk nicht perfekt ist, und versucht nicht, „perfekte Kohärenz" über das gesamte Gebäude zu erzwingen. Stattdessen gibt es der Anwendung die Werkzeuge, um die Reihenfolge nur bei Bedarf zu verwalten, was es ermöglicht, auf Tausende von Servern zu skalieren, ohne den Leistungsabfall zu erleben, der in anderen Systemen zu sehen ist.

Zusammenfassung

Stellen Sie sich das alte System als Postamt vor, bei dem Sie zum Schalter laufen, ein Formular ausfüllen, in der Schlange warten und für jeden einzelnen Brief eine Quittung erhalten müssen.
Stellen Sie sich das neue OpenURMA-System als einen privaten Kurier vor, der direkt neben Ihnen sitzt, genau weiß, mit wem Sie sprechen, und einen Brief sofort in Ihre Hand legen kann, ohne irgendwelche Papiere, es sei denn, Sie bitten ausdrücklich um eine Quittung.

Das Papier beweist, dass diese neue Art der Netzwerkorganisation nicht nur eine Theorie ist, sondern ein funktionierendes, offenes Design, das deutlich schneller und besser skalierbar ist als das, was wir heute verwenden.

Technische Zusammenfassung: OpenURMA

Problemstellung
Moderne RDMA (Remote Direct Memory Access) in Rechenzentren ist strukturell durch die aus InfiniBand und RoCE übernommene „Peripherie-NIC"-Abstraktion limitiert. In diesem Modell befindet sich die Network Interface Card (NIC) hinter dem PCIe-Bus, und die Kommunikation folgt einem Queue-Pair (QP)-Programmierungsmodell. Dieses Design verursacht zwei kritische Kosten, die für KI-Trainingsworkloads mit massiven Fanouts (Tausende von GPUs) und kleinen Nachrichtengrößen (64-Byte-Gradienten) nicht mehr tragbar sind:

Zustandsexplosion: Ein QP verschmilzt die Identität der Anwendung mit der Zuverlässigkeit des Transports und erfordert pro Verbindung einen Zustand für jedes Paar (lokale Anwendung, entfernter Endpunkt). Bei einer Skalierung von 1024x1024 sind hierfür ca. 537 MB Zustand erforderlich, was den on-Chip-SRAM übersteigt und Operationen zwingt, einen PCIe-Roundtrip zu bezahlen, um den Kontext neu zu laden.
PCIe-Durchlauf-Latenz: Da die NIC eine Peripheriekomponente ist, durchquert jede Operation viermal die PCIe-Grenze (Doorbell-MMIO, WQE-DMA-Abfrage, CQE-DMA-Schreibzugriff und CPU-Poll-Fehlschlag). Bei einer 64-Byte-Operation verbrauchen diese Durchläufe ca. 1,5 µs von einem Roundtrip von ca. 2 µs und erhöhen die Latenz um eine Größenordnung über die Leitungsgeschwindigkeit hinaus.

Vorherige Arbeiten (Software-Patches wie FaSST, Hardware-Optimierungen wie SRNIC oder programmierbare Substrate) haben Symptome behandelt, die fundamentale Abstraktion jedoch intakt gelassen.

Methodik
Die Arbeit stellt OpenURMA vor, die erste Clean-Room-Open-Implementierung der Spezifikation von Huaweis Unified Bus (UB) (2025), welche die Peripherie-NIC-Abstraktion ersetzt. UB entkoppelt den pro-Anwendung-Endpunkt-Zustand vom pro-Host-Transportzustand, verlagert den Controller auf den On-Chip-Bus und macht die Reihenfolge als optionalen (opt-in) Feature zugänglich.

Die Implementierung erfolgt mit der OpenClickNP-Toolchain, die eine einzige Quellbeschreibung in drei Modellierungsebenen herunterbricht, um einen rigorosen, direkten Vergleich (Apples-to-Apples) gegen eine abgestimmte OpenRoCE-Basislinie (RoCEv2 RC) zu ermöglichen:

Synthetisierbares RTL: Implementiert auf einem Alveo U50 FPGA, mit einer Taktrate von 322 MHz.
Zyklusgenaue Simulation: Ein Zwei-Knoten-SystemC-Simulator, der beide Endpunkte, die Leitung und die Speicherebenen modelliert.
Vollsystem-Scaffold: Eine gem5-Umgebung, die echte ARM-Binärdateien und einen Linux-Treiber gegen den SystemC-NIC ausführt.

Die Evaluierungsmethodik berücksichtigt explizit bidirektionale Kosten, einschließlich NIC-zu-DRAM-Transfers auf der Zielseite und PCIe-Durchläufe, und vermeidet die in der vorherigen Literatur üblichen „nur-Submit"-Latenzmessungen.

Wesentliche architektonische Maßnahmen
OpenURMA implementiert vier architektonische Maßnahmen, die in der UB-Spezifikation definiert sind:

Schichtentrennung (Begrenzter Zustand): Trennt die Transaktionsschicht (pro-Anwendung Jetty) von der Transportschicht (pro-Host TP Channel). Der Zustand skaliert additiv als $O(N+M)$ statt multiplikativ als $O(N \cdot M)$ .
On-Chip-Controller: Mit einem auf ca. 110 KB begrenzten Zustand (passt in On-Chip-SRAM) befindet sich der Controller auf dem On-Chip-Bus der CPU und eliminiert die PCIe-Grenze.
Load/Store-Pfad: Die CPU kann über native ld/st-Anweisungen direkt auf den Controller zugreifen, um auf entfernten Speicher zuzugreifen, und umgeht dabei Warteschlangen, Doorbells und DMA.
Opt-in-Reihenfolge: Die Reihenfolge wird als vier orthogonale Achsen (Service-Modus, Ausführungsreihenfolge, Fence, Abschlussreihenfolge) exponiert, die Anwendungen optional aktivieren. Die Gate-Logik nutzt bestehende Zähler wieder und fügt für nicht geordnete Operationen keine Pipeline-Zyklen hinzu.

Wesentliche Ergebnisse
Beim kanonischen 64-Byte-Remote-Fetch (LOAD auf UB vs. READ auf RoCEv2):

Latenz: Der Load/Store-Pfad von UB erreicht eine End-to-End-Latenz von ca. 500 ns, eine 4,37-fache Reduktion im Vergleich zur abgestimmten RoCE-DMA-Basislinie (2186 ns). Selbst bei Verbs, die den Work-Queue-Pfad erfordern, ist UB aufgrund der Eliminierung von PCIe-Durchläufen ca. 2,2-mal schneller.
Durchsatz: UB erzielt einen 2,80-fach höheren Work-Request-Durchsatz als OpenRoCE.
Zustandsskalierung: Bei 1024x1024 Endpunkten verwendet OpenURMA 110,6 KB Zustand gegenüber 536,9 MB für RoCE, eine 4.855-fache Reduktion. Dies verhindert die „Latenz-Klippe", bei der sich die RoCE-Leistung drastisch verschlechtert, sobald die Verbindungszahl ca. 23 überschreitet (SRAM-Auslaufpunkt).
Kosten der Reihenfolge: Opt-in-Reihenfolge ist „nahezu kostenlos"; Operationen, die die Gate-Logik umgehen, verursachen keine Pipeline-Zyklen.
Zuverlässigkeit und Stau: OpenURMA implementiert selektive Bestätigung (SACK) und einen C-AQM-Staucontroller und zeigt unter Verlustbedingungen eine überlegene Goodput- und Tail-Latenz im Vergleich zu Go-Back-N und DCQCN.
Skalierung nach außen vs. kohärente Fabrics: Die Arbeit argumentiert, dass kohärente Fabrics (CXL, NVLink) aufgrund des Wachstums des Verzeichniszustands ( $O(N)$ ) und der Kosten für Invalidierungs-Broadcasts nicht auf Rack-Ebene skalieren können. Der nicht-kohärente, opt-in-Ansatz von UB vermeidet diese Klippen und hält die Latenz flach, während die Clustergröße zunimmt.

Bedeutung und Behauptungen
Die Arbeit behauptet, dass OpenURMA die erste empirische Validierung der architektonischen Versprechen des Unified-Bus-Protokolls ohne Rückgriff auf geschlossene Siliziumchips liefert. Die Bedeutung liegt darin zu demonstrieren, dass die drei architektonischen Verpflichtungen – begrenzter Zustand, Controller auf dem Bus und opt-in-Reihenfolge – gegenseitig tragend sind:

Begrenzter Zustand ist erforderlich, um den Controller on-Chip zu halten.
Der On-Chip-Controller ist erforderlich, um den Load/Store-Pfad zu ermöglichen.
Die Schichtentrennung ist erforderlich, um opt-in-Reihenfolge kostengünstig zu machen.

Die Autoren kommen zu dem Schluss, dass OpenURMA die Peripherie-NIC-Abstraktion durch ein Peer-to-Peer-Modell ersetzt, das für KI-Trainingsworkloads skaliert und einen Weg zu submikrosekundigem Remote-Memory-Zugriff bietet, der unter dem aktuellen PCIe/QP-Paradigma strukturell unmöglich ist. Die Implementierung wird als Open-Source-RTL und Simulations-Harness freigegeben, um weitere Forschung und Prototypenentwicklung zu ermöglichen.