100GbE-Paketverlust: PCIe-Engpässe im Server beheben

Währenddessen steckt die eigentliche Bremse oft direkt unter der Karte: ein PCIe-Steckplatz mit zu wenig Lanes, eine ungünstige Sockel-Anbindung oder eine DMA-Konfiguration, die der Karte ihre Transfers in kleinen Portionen serviert.

Bei den 100GbE-Netzwerkkarte-Paketverlust-Ursachen muss deshalb die Reihenfolge stimmen. Erst die physische Datenautobahn prüfen, dann die Interrupt- und Speicherpfade, erst zuletzt über Feinparameter am Netzwerkprotokoll reden. Wer diesen Ablauf umdreht, investiert Stunden in Symptome und lässt den Engpass unangetastet.

Eine 100GbE-Karte ist kein isoliertes Bauteil. Sie verkauft nur dann 100 Gigabit, wenn PCIe-Topologie, CPU-Sockel und Speicherpfad die Rechnung mittragen.

PCIe-Bandbreite: Warum Gen3 x8 bei 100GbE rechnerisch verliert

Die verbreitetste Fehlkalkulation im Einkauf klingt harmlos: „Die Karte hat einen x16-Stecker, der freie Steckplatz ist x8, das wird schon gehen.“ Mechanisch geht es. Wirtschaftlich und technisch wird daraus schnell eine Fehlallokation.

PCIe 3.0 x8 liefert effektiv rund 63 Gbit/s beziehungsweise etwa 7,88 GB/s. Eine einzelne 100GbE-Karte kann über diesen Slot also niemals ihren nominellen Portdurchsatz erreichen. Das ist kein Treiberfehler und auch keine schlechte Firmware. Es ist schlicht ein physikalisches Limit. Die 128b/130b-Kodierung von PCIe Gen3 und Gen4 arbeitet zwar mit rund 98,46 Prozent Effizienz; der relevante Engpass bleibt trotzdem die Zahl der verfügbaren Lanes.

Für einen einzelnen 100GbE-Port sind mindestens PCIe 3.0 x16 oder PCIe 4.0 x8 erforderlich. Für Dual-Port-100GbE gilt eine deutlich härtere Regel: Soll an beiden Ports gleichzeitig Volllast möglich sein, braucht die Karte PCIe 4.0 x16. PCIe 4.0 x8 reicht dort nicht als dauerhafte Grundlage für 200 Gbit/s Nutzverkehr.

Die Tabelle ist nicht als Datenblattfolklore zu lesen. Sie entscheidet über die Frage, ob eine Netzwerkkarte produktiv nutzbar ist oder nur im Inventarsystem gut aussieht.

Besonders tückisch sind Server-Mainboards, deren Steckplätze physisch x16 ausgeführt sind, elektrisch aber abhängig von Bestückung, Prozessor oder Riser-Karte nur mit x8 laufen. Auch Bifurcation-Konfigurationen spielen hinein: Ein Slot wird dann beispielsweise in zwei x8-Verbindungen aufgeteilt. Für Storage-Adapter oder Beschleuniger kann das sinnvoll sein. Für eine 100GbE-Karte im falschen Teil dieser Aufteilung entsteht daraus ein garantierter Durchsatzdeckel.

Die reale Link-Breite lässt sich unter Linux mit lspci und der ausführlichen Geräteansicht kontrollieren. Entscheidend sind dabei nicht nur die maximal mögliche Breite und Geschwindigkeit des Controllers, sondern der tatsächlich ausgehandelte Zustand. Ein Gerät kann Gen4 x16 unterstützen und trotzdem als Gen3 x8 laufen, wenn Slot, Riser, BIOS-Konfiguration oder CPU-Lane-Zuordnung es erzwingen.

Prüfen Sie in dieser Reihenfolge:

1. PCIe-Generation und Lane-Breite des aktiven Links: Die Karte muss mit der erwarteten Generation und Breite angebunden sein. Ein Gen4-fähiger Adapter in einem Gen3-x8-Pfad bleibt ein Gen3-x8-Adapter, unabhängig vom Aufdruck auf der Verpackung.

2. Zuordnung des Steckplatzes im Mainboard-Handbuch: Nicht jeder lange Slot hängt direkt an der CPU. Manche Lanes laufen über Chipsatz oder Switches; das verändert Latenz, Bandbreitenreserve und Fehlerbild.

3. Riser- und Backplane-Spezifikation: Gerade bei dichten 1U- und 2U-Systemen entscheidet der Riser über die tatsächlich erreichbare Link-Breite. Ein ungeeigneter Riser ist kein kleines Zubehörproblem, sondern Teil der Datenpfadarchitektur.

4. Belegung benachbarter Steckplätze: Zusätzliche GPUs, NVMe-Adapter oder RAID-Controller können Lane-Aufteilungen auslösen. Was im leeren Testsystem sauber läuft, muss nach dem Vollausbau nicht mehr gelten.

5. Portzahl und Lastprofil: Ein Dual-Port-Adapter darf nicht anhand eines einzelnen Iperf-Streams freigesprochen werden. Relevant ist die gleichzeitige Last beider Ports, inklusive Storage- oder Replikationsverkehr.

Der klassische Fehler in der Beschaffung: Die NIC wird als Einzelposition bewertet, das Mainboard als bestehende Plattform abgehakt. Bei 100GbE gehört beides in dieselbe TCO-Rechnung. Der vermeintlich günstige freie x8-Slot kann eine Karte mit vierstelligem Anschaffungswert auf rund 63 Gbit/s begrenzen. Das ist keine Einsparung, sondern ein sehr teurer Flaschenhals.

MRRS: Wenn DMA in zu kleinen Portionen arbeitet

Ist die PCIe-Anbindung korrekt, kommt die nächste Ebene: die DMA-Transfers der Karte. Eine 100GbE-NIC verschiebt Daten nicht Paket für Paket romantisch über die CPU, sondern arbeitet über Direct Memory Access. Dafür fordert sie Lesevorgänge im Speicher- und PCIe-Pfad an. Die Größe dieser Anforderungen wird unter anderem durch die Max Read Request Size, kurz MRRS, beeinflusst.

MRRS kann in Stufen von 128, 256, 512, 1024, 2048 bis 4096 Byte konfiguriert sein. Läuft die Karte mit 512 Byte, obwohl der Pfad 4096 Byte unterstützt, entstehen mehr einzelne Transaktionen. Mehr Verwaltungsaufwand, mehr Overhead, weniger wirksamer Datendurchsatz. Bei moderater Last bleibt das oft unsichtbar. Bei dauerhaft hoher Paketfrequenz wird es zum Kostenfaktor in Form von CPU-Zeit, Latenz und verlorenen Paketen.

Eine MRRS-Anpassung erfolgt auf Linux-Systemen typischerweise über setpci. Der relevante Wert muss jedoch vorher sauber ermittelt werden. Blindes Setzen eines Maximalwerts ist keine professionelle Betriebsstrategie: BIOS, PCIe-Switch, Riser und Endgerät müssen die Konfiguration unterstützen. Nach einem Neustart kann außerdem die Firmware wieder ihre Standardwerte durchsetzen.

Der saubere Ablauf sieht so aus:

1. PCIe-Adresse der Netzwerkkarte mit lspci bestimmen.

2. Die ausführlichen Capability-Informationen des Geräts auslesen und aktuelle MRRS- sowie MPS-Werte dokumentieren.

3. Prüfen, ob das BIOS bereits eine Vorgabe für PCIe-Payload oder Read-Request-Parameter setzt.

4. MRRS testweise auf einen höheren, vom Gerät unterstützten Wert anheben – bis maximal 4096 Byte.

5. Unter reproduzierbarer Last messen: Durchsatz, Paketverluste, CPU-Auslastung und Latenz gehören in denselben Testlauf.

6. Die Einstellung nach Neustart und Firmware-Updates erneut kontrollieren.

MPS, die Max Payload Size, ist ein verwandter, aber nicht identischer Wert. Typische Konfigurationen liegen zwischen 128 und 512 Byte; theoretisch sind höhere Werte möglich. MRRS bestimmt, wie groß eine Leseanforderung ausfallen darf, MPS die Größe von Nutzdatenpaketen in bestimmten PCIe-Transaktionen. Wer beide Begriffe vermischt, ändert häufig den falschen Regler und erklärt anschließend die unveränderte Lage zum Treiberproblem.

Kleine PCIe-Transfers sind bei 100GbE keine harmlose Feineinstellung. Unter Dauerlast addiert sich ihr Overhead zu echter verlorener Kapazität.

MRRS-Tuning repariert allerdings keinen unterdimensionierten Slot. Eine Karte in PCIe 3.0 x8 bleibt auf etwa 63 Gbit/s begrenzt, auch wenn jede Read Request perfekt konfiguriert ist. Das muss so deutlich gesagt werden, weil Hersteller- und Treiberempfehlungen gern den Eindruck vermitteln, ein Parameter-Set könne Architektur ersetzen. Kann es nicht.

RX-Ring-Puffer: Paketverluste auf Hardware-Ebene erkennen

Wenn die PCIe-Bandbreite stimmt und DMA nicht künstlich kleinteilig arbeitet, richtet sich der Blick auf die Empfangsseite der Karte. Der RX-Ring-Puffer, oft schlicht RX-Ring genannt, hält Deskriptoren für eingehende Pakete bereit. Ist dieser Ring voll, bevor Kernel und CPU die Pakete abarbeiten können, verwirft die Netzwerkkarte die folgenden Frames direkt auf Hardware-Ebene.

Das ist ein wichtiger Unterschied. Ein verworfenes Paket im RX-Ring ist nicht primär ein Routing-, Firewall- oder Anwendungsthema. Es zeigt, dass die Karte Daten schneller annimmt, als der Host sie aus ihrem Puffer abholt. Bei 100GbE kann dieses Zeitfenster sehr klein sein.

Mit ethtool -g lässt sich die aktuelle sowie die maximal unterstützte Ring-Größe abfragen. Abhängig von NIC und Treiber finden sich Werte wie 256, 1024, 4096 oder 8192 Deskriptoren. Über ethtool -G kann der RX-Ring bis zum vom Adapter erlaubten Maximum vergrößert werden.

Ein größerer Ring ist kein Freifahrtschein. Er verschiebt die Grenze, an der kurze Lastspitzen zu Verlusten führen, und gibt der CPU mehr Zeit zur Abarbeitung. Bei konstant überforderter CPU oder falscher NUMA-Platzierung wächst dagegen nur die Warteschlange. Die Latenz steigt, und irgendwann ist auch der große Puffer voll.

Die richtige Interpretation der Zähler ist daher entscheidend:

• RX-Drops steigen bei Bursts, nicht bei Dauerlast: Ein größerer Ring kann sinnvoll sein. Typisch sind Mikrobursts aus Storage, Backup, Ost-West-Verkehr oder mehreren gleichzeitig sendenden Hosts.
• RX-Drops steigen proportional zum Traffic: Erst CPU-Last, IRQ-Verteilung, NUMA-Topologie und PCIe-Pfad untersuchen. Ein Ring von 4096 statt 1024 Deskriptoren kaschiert dann höchstens die Diagnose.
• Keine Drops auf der NIC, aber Verluste in der Anwendung: Der Engpass sitzt möglicherweise höher im Kernel-Netzwerkstack, in der Anwendung oder in den Socket-Puffern. Der Adapter ist dann nicht der Täter.
• Drops beginnen erst nach Aktivierung eines zweiten Ports: Die PCIe-Anbindung ist ein Hauptverdächtiger. Bei Dual-Port-100GbE ist Gen4 x16 die notwendige Ausgangsbasis für Volllast auf beiden Ports.

Für den Betrieb zählt nicht nur der höchste erzielte Durchsatz, sondern die Stabilität der Counter über längere Lastintervalle. Ein fünfminütiger Test ohne Verlust ist bei 100GbE eine Momentaufnahme. Backup-Fenster, Replikation, virtuelle Maschinen und parallele Storage-Transfers erzeugen andere Paketmuster als ein synthetischer Einzelstrom.

NUMA: Der teure Umweg über den zweiten Sockel

In Zwei-Sockel-Servern wird die Netzwerkkarte einem NUMA-Knoten zugeordnet. Sitzt die NIC an Sockel 0, verarbeitet aber Sockel 1 ihre Interrupts und Anwendungs-Threads, muss der Datenverkehr über den Inter-Socket-Link wandern – etwa über UPI oder Infinity Fabric. Das kostet zusätzliche Latenz und belastet Ressourcen, die für andere Workloads vorgesehen waren.

Bei geringer Last bleibt ein NUMA-Misalignment oft folgenlos. Unter 100GbE-Dauerlast wird daraus ein handfester Engpass. Die Karte schreibt per DMA in Speicher, Kerne auf dem anderen Sockel holen Daten über den Interconnect, Interrupts treffen auf nicht-lokale CPUs, Caches werden unnötig invalidiert. Das System arbeitet. Nur eben mit einem Umweg, den niemand budgetiert hat.

Die Zuordnung der PCIe-Geräte zu NUMA-Knoten sollte deshalb vor jeder Treiberakrobatik geprüft werden. Unter Linux liefern Systeminformationen zum PCIe-Gerät und zur CPU-Topologie die erforderlichen Hinweise. Danach werden IRQ-Affinität, RSS-Queues und die CPU-Bindung datenintensiver Prozesse auf denselben NUMA-Knoten gelegt wie die NIC.

Praktisch bedeutet das:

• Die Netzwerkkarte in einen Slot setzen, der an den Sockel mit der vorgesehenen Workload gebunden ist.
• IRQs der NIC auf lokale CPU-Kerne verteilen, statt sie dem allgemeinen Balancing zu überlassen.
• RSS-Queues nicht über beide Sockel verstreuen, wenn der Haupttraffic an einer einzelnen NIC hängt.
• Virtuelle Maschinen oder Container mit hoher Netzlast möglichst auf dem lokalen NUMA-Knoten der Karte platzieren.
• Bei Storage over Ethernet auch die Nähe von NIC, NVMe-Controller und Arbeitsspeicherpfad betrachten. Zwei getrennte Datenpfade über denselben Interconnect sind keine elegante Architektur, sondern eine Einladung zu Lastspitzen.

Hier zeigt sich der Unterschied zwischen einer Systemintegration und einem Teilekauf. Zwei Server können dieselbe CPU, dieselbe 100GbE-Karte und denselben Speicher besitzen – und trotzdem massiv unterschiedliche Verlustwerte liefern, weil Slotwahl und Affinität anders gesetzt sind.

Der Diagnose-Workflow: Erst messen, dann verändern

Bei Netzwerkkarte-100GbE-Durchsatzproblemen ist Aktionismus teuer. Wer gleichzeitig Treiber, Ring-Puffer, MTU, IRQ-Parameter und BIOS verstellt, produziert keine Optimierung, sondern verliert die Vergleichbarkeit. Ein belastbarer Ablauf reduziert den Aufwand und macht Ergebnisse reproduzierbar.

1. Verlustort eindeutig bestimmen

Zuerst wird geklärt, ob Pakete auf der Netzwerkkarte, im Kernel, im Switch oder in der Anwendung verschwinden. Die Interface-Statistiken und erweiterten Treiberzähler aus ethtool -S sind dabei zentral. Steigende RX-Drop- oder Miss-Zähler auf der NIC weisen auf einen hostseitigen Empfangsengpass hin.

Switch-Zähler ergänzen die Sicht, ersetzen sie aber nicht. Ein sauberer Switch-Port beweist nur, dass der Switch seine Frames übergeben hat. Er beweist nicht, dass der Server sie schnell genug aus seinem RX-Ring abgeholt hat.

2. PCIe-Link tatsächlich auslesen

Danach folgt lspci mit detaillierter Ausgabe. Dokumentiert werden:

• aktuelle und maximal unterstützte Link-Geschwindigkeit,
• aktuelle und maximal mögliche Lane-Breite,
• PCIe-Adresse der NIC,
• MRRS- und MPS-Konfiguration,
• Zuordnung zu einem NUMA-Knoten.

Die Soll-Konfiguration wird gegen das Mainboard- und Riser-Design geprüft. Besonders bei gebraucht beschafften Servern oder nach Umbauten ist das Pflicht. Ein Riser aus einer anderen Chassis-Variante, ein BIOS-Reset oder eine zusätzliche Beschleunigerkarte reichen, um die Lane-Zuteilung zu verändern.

3. Ring-Größe und Queue-Verhalten erfassen

Mit ethtool -g wird die RX-Ring-Konfiguration aufgenommen. Danach erfolgt eine definierte Lastmessung mit dem aktuellen Wert. Erst wenn Hardware-Drops bei Burst-Last sichtbar sind und PCIe sowie NUMA plausibel aussehen, ist eine Erhöhung des Rings sinnvoll.

Die Änderung mit ethtool -G sollte einzeln erfolgen. Nicht parallel mit IRQ-Tuning, MRRS-Anpassungen oder Treiberwechseln. Sonst weiß hinterher jeder, dass „etwas besser wurde“, aber niemand kann die Einstellung verlässlich in die Betriebsdokumentation übernehmen.

4. NUMA-Affinität herstellen

Im nächsten Schritt werden NIC, IRQs und verarbeitende Threads auf denselben Sockel ausgerichtet. Bei virtualisierten Hosts gehört die Platzierung der VMs dazu. Bei Datenbank- oder Storage-Servern gilt dasselbe für Prozesse mit hohem Netzwerkanteil.

Die Messung muss nun nicht nur Gigabit pro Sekunde abbilden, sondern auch CPU-Auslastung pro NUMA-Knoten, Interrupt-Verteilung und Latenz. Ein Durchsatzwert ohne CPU- und Drop-Zähler ist im B2B-Betrieb kaum aussagekräftig. Die Hardware kann einen Test „bestehen“ und dennoch bei der nächsten Lastspitze kippen.

5. Erst am Ende Treiber und Firmware bewerten

Firmware-Updates und aktuelle Treiber gehören in ein kontrolliertes Lifecycle-Management. Sie sind aber nicht der erste Hebel, wenn ein Adapter mit PCIe 3.0 x8 angebunden ist oder seine Daten über den falschen Sockel schiebt. Software kann Kompatibilität und Verhalten verbessern. Sie vermehrt keine PCIe-Lanes.

Gerade im Einkauf wird dieser Punkt gern verdrängt, weil ein Firmware-Update keine zusätzliche Stückliste erzeugt. Der Umbau auf einen geeigneten Slot, ein anderer Riser oder ein Plattformwechsel kostet dagegen Budget und Wartungsfenster. Nur: Die Kosten verschwinden nicht, wenn man sie ignoriert. Sie tauchen später als schlechte Replikationszeiten, unzuverlässige Sicherungsfenster und operative Fehlersuche wieder auf.

Die typische Fehlersuche, die Zeit verbrennt

Einige Maßnahmen werden bei Paketverlust reflexhaft empfohlen. Sie sind nicht immer falsch, aber in der falschen Reihenfolge schlicht ineffizient.

MTU erhöhen: Jumbo Frames können die Paketverarbeitungsrate senken, lösen aber keine PCIe-Unterversorgung. Ein 100GbE-Adapter in Gen3 x8 bleibt limitiert, egal wie groß die Ethernet-Frames sind.

RX-Ring auf Maximum setzen: Hilft bei Burst-Problemen. Bei dauerhaftem PCIe-Engpass, CPU-Sättigung oder NUMA-Fernzugriff wird nur die Zeit bis zum nächsten Drop verlängert.

Treiber neu installieren: Kann bei konkreten Defekten oder Versionsproblemen notwendig sein. Ohne belastbaren Hinweis ist es die klassische Maßnahme, weil sie beschäftigt aussieht und kaum Architekturverständnis verlangt.

Den Switch austauschen: Wenn die lokalen NIC-Zähler auf Empfangsverluste hinweisen, ist ein neuer Switch meist ein kostspieliger Umweg. Erst den Serverpfad bereinigen.

Dual-Port-Karte in Gen4 x8 betreiben und auf „nicht gleichzeitig volle Last“ hoffen: Das kann in einer ruhigen Umgebung zunächst funktionieren. Für Kapazitätsplanung ist es keine belastbare Grundlage. Infrastruktur wird für die Spitzenlast beschafft, nicht für den Dienstagvormittag ohne Backup-Fenster.

Die Beschaffungsentscheidung: Bandbreite als Plattformmerkmal behandeln

Die konkrete Handlungsempfehlung für den Einkauf ist unspektakulär, aber wirksam: Eine 100GbE-NIC darf nicht mehr als Einzelkomponente ausgeschrieben werden. In die Freigabe gehören Kartenmodell, Portzahl, benötigte PCIe-Generation, Lane-Breite, Riser-Variante und NUMA-Zuordnung des Zielsystems.

Für einen einzelnen 100GbE-Port ist PCIe 3.0 x16 oder PCIe 4.0 x8 die Untergrenze. Für zwei gleichzeitig hoch ausgelastete 100GbE-Ports ist PCIe 4.0 x16 einzuplanen. Alles darunter ist keine mutige Optimierung, sondern eine Wette gegen die Physik.

Danach kommen MRRS, RX-Ring und NUMA-Affinität. Diese drei Stellschrauben entscheiden darüber, ob die vorhandene Plattform ihre Bandbreite auch unter realer Last sauber in Nutzdurchsatz übersetzt. Sie ersetzen aber keine solide PCIe-Architektur.

Wer 100GbE-Paketverluste dauerhaft beheben will, beginnt deshalb nicht beim Kabel und nicht beim Marketingversprechen der Karte. Er liest den tatsächlichen PCIe-Link aus, ordnet die NIC dem richtigen Sockel zu, misst die Hardware-Zähler und dokumentiert jede Änderung. Das ist weniger spektakulär als ein großer Hardwaretausch. Im Betrieb ist es fast immer die günstigere Rechnung.