🤖 AI

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

Dit artikel introduceert OpenURMA, de eerste clean-room open-source implementatie van Huawei's Unified Bus-protocol, die via RTL-, SystemC- en gem5-simulaties aantoont dat het ontkoppelen van per-toepassing staat van transportstaat de 64-byte remote fetch-latentie met 4,37x verlaagt en de doorvoer met 2,80x verhoogt ten opzichte van traditionele RoCEv2-baselines.

Oorspronkelijke auteurs: Bojie Li

Gepubliceerd 2026-05-28

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Bojie Li

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Het Grote Probleem: De "Perifere" Bottleneck

Stel je een modern datacentrum voor als een enorm kantoorgebouw waar duizenden medewerkers (toepassingen) onmiddellijk met elkaar moeten communiceren.

Op dit moment verloopt de standaardcommunicatie als volgt:

Het Perifere Probleem: De netwerkkaart (NIC) wordt behandeld als een perifeer apparaat, vergelijkbaar met een printer of muis die op een computer is aangesloten. Het zit "buiten" het hoofd (de CPU).
Het Wachtrij-systeem: Om een bericht te sturen, moet een medewerker een briefje schrijven (een "Work Request"), dit naar het postvak van de netwerkkaart brengen (de "Doorbell") en wachten. De netwerkkaart pakt het vervolgens op, verwerkt het en schrijft een "Klaar"-briefje terug naar het postvak.
De File: Omdat de netwerkkaart "buiten" zit, moet elk enkel briefje vier keer een drukke snelweg (de PCIe-bus) oversteken om alleen maar verzonden en bevestigd te worden.
De Geheugencrisis: De netwerkkaart moet een persoonlijke map bewaren voor elk paar medewerkers dat met elkaar communiceert. Als je 1.000 medewerkers hebt die met 1.000 anderen praten, heeft de kaart 1 miljoen mappen nodig. Het raakt zijn bureauruimte (on-chip geheugen) op en moet naar het archief in de kelder (host RAM) rennen om bestanden te halen. Dit vertraagt alles tot een kruipend tempo.

Het Resultaat: Hoewel de internetkabels (de "draad") ongelooflijk snel zijn, zit het hele systeem vast in de file vanwege de manier waarop de netwerkkaart is aangesloten en georganiseerd.

De Oplossing: Huawei's Unified Bus (UB)

Huawei heeft een nieuw ontwerp voorgesteld genaamd Unified Bus (UB) (in hun Ascend 950-chip) om dit op te lossen. Ze hebben niet alleen het oude systeem gerepareerd; ze hebben de verkeersregels veranderd.

1. Het Kantoor Verplaatsen Naar Binnen in het Gebouw
In plaats van dat de netwerkkaart een perifeer apparaat buiten het gebouw is, plaatst UB de netwerkcontroller binnen in het gebouw in de hoofdgang (de on-chip bus).

Analogie: In plaats van naar de lobby te lopen om een brief te posten, kun je deze nu gewoon aan een collega overhandigen die direct naast je bureau staat. Je hoeft de snelweg niet vier keer over te steken; je zet gewoon één stap.

2. Het Opsplitsen van het Archiefsysteem
Het oude systeem hield één enorme map bij voor elk paar mensen dat praat. UB splitst dit op:

Jetty: Een kleine kaart voor jouw kant van het gesprek.
TP-kanaal: Een gedeelde kaart voor de kant van de andere persoon.
Analogie: In plaats van een unieke map nodig te hebben voor elk paar mensen (wat in omvang explodeert), heb je alleen een kaart voor jezelf en een gedeelde kaart nodig voor de persoon met wie je praat. Het totale aantal mappen groeit langzaam (additief) in plaats van te exploderen (multiplicatief). Dit voorkomt dat het bureauruimte van de netwerkkaart volloopt.

3. De "Load/Store"-Shortcut
Omdat de controller nu binnen in het gebouw zit, kan de CPU direct met hem communiceren via standaard instructies (zoals LOAD of STORE), net als het lezen van een variabele in een programma.

Analogie: Je hoeft geen formulier in te vullen, naar het postvak te lopen en op een ontvangstbewijs te wachten. Je pakt gewoon direct de data die je nodig hebt.

4. Optionele Regels (Opt-in Ordering)
Het oude systeem dwong strenge regels af: "Je moet berichten ontvangen in de exacte volgorde waarin ze zijn verzonden, ongeacht wat." Dit is traag en onnodig voor veel taken.

Analogie: UB zegt: "We kunnen berichten zo snel mogelijk bezorgen. Als je ze echt in de juiste volgorde nodig hebt, til dan je hand op en we vertragen om ze te sorteren. Als het je niet uitmaakt, gooien we ze gewoon in je inbox zoals ze aankomen." Dit bespaart tijd voor iedereen die geen strikte volgorde nodig heeft.

Wat OpenURMA Heeft Gedaan

De chip van Huawei bestaat, maar het is een "black box". Niemand kan zien hoe het van binnen werkt, het meten of erop bouwen.

OpenURMA is de eerste open-source, clean-room-implementatie van dit nieuwe systeem.

"Clean-room" betekent dat ze het vanaf nul hebben gebouwd met alleen het publieke regelboek (de specificatie), zonder naar de geheime code van Huawei te kijken.
Ze hebben drie versies gebouwd om het te testen:
1. RTL: De daadwerkelijke blauwdruk voor hardwarechips (getest op een FPGA-kaart).
2. SystemC: Een supergedetailleerde computersimulatie van het netwerk.
3. gem5: Een volledige computersimulatie die een echt besturingssysteem draait.

Ze hebben hun nieuwe systeem (OpenURMA) vergeleken met de oude standaard (RoCEv2) met exact dezelfde tools om een eerlijke strijd te garanderen.

De Resultaten: Hoeveel Sneller?

Het paper claimt enorme verbeteringen, specifiek voor kleine, snelle bewerkingen (zoals het ophalen van een klein stukje data):

Snelheid: Het nieuwe systeem is 4,37 keer sneller (ongeveer 500 nanoseconden) dan het oude systeem (ongeveer 2.186 nanoseconden) voor een standaard data-ophaalbewerking.
Doorvoer: Het kan 2,8 keer meer data per seconde verwerken.
Efficiëntie: Het gebruikt zeer weinig ruimte op de chip (slechts ongeveer 14% van de beschikbare ruimte op een testbord).
Schalbaarheid: Naarmate je meer gebruikers toevoegt (van 1 tot 1.024), vertraagt het oude systeem drastisch omdat het zijn bureauruimte opgebruikt. Het nieuwe systeem blijft snel en stabiel omdat zijn archiefsysteem efficiënt is.

Waarom Dit Belangrijk Is (Volgens het Paper)

Het paper betoogt dat de huidige manier waarop we computers in datacentra verbinden (door de netwerkkaart te behandelen als een perifeer apparaat) fundamenteel gebroken is voor moderne AI- en big data-werklasten.

Het "Coherent" Alternatief: Er zijn andere technologieën (zoals CXL of NVLink) die proberen het geheugen "gedeeld" en "coherent" te laten lijken. Het paper betoogt echter dat deze technologieën bezwijken wanneer je ze probeert op te schalen naar grote clusters (vele racks met servers), omdat ze te veel status-tracking vereisen en slecht kunnen omgaan met netwerkfouten.
Het UB-voordeel: UB accepteert dat het netwerk niet perfect is en probeert niet "perfecte coherentie" te forceren over het hele gebouw. In plaats daarvan geeft het de applicatie de tools om de volgorde alleen te beheren wanneer nodig, waardoor het kan schalen naar duizenden servers zonder de prestatie-inzinking die in andere systemen wordt gezien.

Samenvatting

Denk aan het oude systeem als een postkantoor waar je naar de balie moet lopen, een formulier moet invullen, in de rij moet staan en een ontvangstbewijs moet krijgen voor elk enkel briefje.
Denk aan het nieuwe OpenURMA-systeem als een privékoerier die direct naast je zit, precies weet met wie je praat, en een briefje direct in je hand kan laten vallen zonder enig papierwerk, tenzij je specifiek om een ontvangstbewijs vraagt.

Het paper bewijst dat deze nieuwe manier van het netwerk organiseren niet alleen een theorie is, maar een werkend, open ontwerp dat aanzienlijk sneller en schaalbaarder is dan wat we vandaag de dag gebruiken.

Technische Samenvatting: OpenURMA

Probleemstelling
Moderne datacenter RDMA (Remote Direct Memory Access) is structureel geblokkeerd door de "perifere-NIC"-abstractie die is overgenomen van InfiniBand en RoCE. In dit model bevindt de Network Interface Card (NIC) zich achter de PCIe-bus, en volgt communicatie een Queue-Pair (QP)-programmeermodel. Dit ontwerp legt twee kritieke kosten op die onhoudbaar zijn geworden voor AI-trainingwerklasten die worden gekenmerkt door enorme fanouts (duizenden GPU's) en kleine berichtgroottes (64-byte gradients):

Staatsexplosie: Een QP fuseert applicatie-identiteit met transportbetrouwbaarheid, wat vereist dat er voor elke (lokale applicatie, extern eindpunt)-pair een verbindingsspecifieke staat wordt onderhouden. Bij een schaal van 1024x1024 vereist dit ongeveer 537 MB aan staat, wat de on-chip SRAM overschrijdt en bewerkingen dwingt om een PCIe-ronde te betalen om de context opnieuw op te halen.
PCIe-overschrijdingslatentie: Omdat de NIC een perifeer apparaat is, kruist elke bewerking vier keer de PCIe-grens (doorbell MMIO, WQE DMA-opvraging, CQE DMA-schrijving en CPU-poll-miss). Bij een 64-byte bewerking verbruiken deze overschrijdingen ongeveer 1,5 µs van een totale ronde van ongeveer 2 µs, waardoor de latentie met een orde van grootte wordt opgeblazen boven de lijnsnelheid.

Vorig werk (softwarepatches zoals FaSST, hardwareoptimalisaties zoals SRNIC of programmeerbare substraten) heeft symptomen aangepakt maar de fundamentele abstractie intact gelaten.

Methodologie
Het artikel presenteert OpenURMA, de eerste schone-kamer open implementatie van Huawei's Unified Bus (UB)-specificatie (2025), die de perifere-NIC-abstractie vervangt. UB ontkoppelt per-applicatie eindpuntstaat van per-host transportstaat, verplaatst de controller naar de on-chip bus en blootst ordening als een optioneel (opt-in) kenmerk.

De implementatie is gerealiseerd met de OpenClickNP-toolchain, die een enkele bronbeschrijving omzet in drie modelleringstiers voor een rigoureuze, eerlijke vergelijking ("apples-to-apples") met een overeenkomende OpenRoCE (RoCEv2 RC)-baseline:

Synthetiseerbare RTL: Geïmplementeerd op een Alveo U50 FPGA, met een sluitfrequentie van 322 MHz.
Cyclusniveau-simulatie: Een twee-knooppunt SystemC-simulator die zowel eindpunten, de verbinding als geheugenhierarchieën modelleert.
Volledig-systeemkader: Een gem5-omgeving die echte ARM-binarieën en een Linux-driver draait tegen de SystemC-NIC.

De evaluatiemethodologie houdt expliciet rekening met bidirectionele kosten, inclusief NIC-naar-DRAM-overdrachten aan de doelpuntzijde en PCIe-overschrijdingen, en vermijdt zo de "alleen-indienen"-latentiemetingen die gebruikelijk zijn in eerdere literatuur.

Belangrijkste Architecturale Moves
OpenURMA implementeert vier architecturale moves zoals gedefinieerd in de UB-specificatie:

Laagverdeling (Beperkte Staat): Scheidt de transactielaag (per-applicatie Jetty) van de transportlaag (per-host TP Channel). De staat schaalt additief als $O(N+M)$ in plaats van multiplicatief als $O(N \cdot M)$ .
Controller op Chip: Met een staat die beperkt is tot ongeveer 110 KB (wat past in on-chip SRAM), bevindt de controller zich op de on-chip bus van de CPU, waardoor de PCIe-grens wordt geëlimineerd.
Load/Store-pad: De CPU kan via native ld/st-instructies rechtstreeks naar de controller toegang krijgen tot extern geheugen, waarbij werkqueues, doorbells en DMA worden omzeild.
Optionele Ordening: Ordening wordt blootgelegd als vier orthogonale assen (servicemodus, uitvoeringsvolgorde, fence, voltooiingsvolgorde) waar applicaties voor kiezen. De gatinglogica hergebruikt bestaande tellers en voegt nul pipelinecycli toe voor ongeordende bewerkingen.

Belangrijkste Resultaten
Op de canonieke 64-byte externe ophaalbewerking (LOAD op UB versus READ op RoCEv2):

Latentie: Het load/store-pad van UB bereikt een end-to-end latentie van ongeveer 500 ns, een 4,37× reductie vergeleken met de overeenkomende RoCE DMA-baseline (2186 ns). Zelfs bij verbs die het werkqueue-pad vereisen, is UB ongeveer 2,2× sneller door de eliminatie van PCIe-overschrijdingen.
Doorvoer: UB handhaaft een 2,80× hogere werkverzoek-doorvoer dan OpenRoCE.
Staatsschaal: Bij 1024x1024 eindpunten gebruikt OpenURMA 110,6 KB aan staat versus 536,9 MB voor RoCE, een 4.855× reductie. Dit voorkomt de "latentieklif" waarbij RoCE-prestaties sterk verslechteren zodra het aantal verbindingen ongeveer 23 overschrijdt (het SRAM-uitlooppunt).
Ordeningskosten: Optionele ordening is "bijna gratis"; bewerkingen die de gating omzeilen, kosten nul pipelinecycli.
Betrouwbaarheid & Congestie: OpenURMA implementeert selectieve bevestiging (SACK) en een C-AQM-congestiecontroller, en toont superieure goodput en tail-latentie onder verlies in vergelijking met Go-Back-N en DCQCN.
Schalen versus Coherente Fabrics: Het artikel betoogt dat coherente fabrics (CXL, NVLink) niet kunnen schalen tot rack-niveau vanwege de groei van de directorystaat ( $O(N)$ ) en de kosten van invalidatie-uitzendingen. De niet-coherente, optionele aanpak van UB vermijdt deze kliffen en behoudt een vlakke latentie naarmate de clusteromvang toeneemt.

Betekenis en Claims
Het artikel claimt dat OpenURMA de eerste empirische validatie biedt van de architecturale beloften van het Unified Bus-protocol zonder te vertrouwen op gesloten silicium. De betekenis ligt in het aantonen dat de drie architecturale toezeggingen – beperkte staat, controller op de bus en optionele ordening – onderling dragend zijn:

Beperkte staat is vereist om de controller on-chip te houden.
De controller op de chip is vereist om het load/store-pad mogelijk te maken.
De laagverdeling is vereist om optionele ordening kosteloos te maken.

De auteurs concluderen dat OpenURMA de perifere-NIC-abstractie vervangt door een peer-to-peer-model dat schaalbaar is voor AI-trainingwerklasten, en een weg biedt naar externe geheugentoegang onder de microseconde die structureel onmogelijk is onder het huidige PCIe/QP-paradigma. De implementatie wordt vrijgegeven als open-source RTL en simulatieharnassen om verder onderzoek en prototyping mogelijk te maken.