Zusammenfassung

  • Die Stelle, an der eine Warteschlange Überlastung zu markieren beginnt, ist eine eingestellte Schwelle und kein Wert, der mit der Portgeschwindigkeit mitkommt.
  • Das EOS-Handbuch führt den Markierungsbefehl mit der Chip-Familie daneben — daraus wird die Einheitlichkeit der Fabric zur betrieblichen Arbeit.

Wo die Bremse geschrieben wird

Zunächst der Mechanismus. RFC 3168 bestimmt die Bits 6 und 7 des IPv4-TOS-Oktetts als ECN-Feld, merkt an, dass dasselbe Feld im IPv6-Traffic-Class-Oktett identisch definiert ist, und legt aus zwei Bits vier Codepoints fest: 00 für Not-ECT, 01 für ECT(1), 10 für ECT(0) und 11 für CE, Congestion Experienced. Ein Router, der beginnende Überlast erkennt, setzt auf einem ECN-fähigen Paket die CE-Markierung, statt es zu verwerfen (RFC 3168).

Was die Norm nicht entscheidet, ist die Zahl. Die RFC legt die Bedeutung des Feldes und das Verhalten der markierenden Seite fest. Wo die Markierung einsetzt, gehört dem Betreiber.

Die Konfigurationsfläche, die das Handbuch offenlegt

Die Seite Quality of Service zu EOS 4.37.0F von Arista benennt genau, wo diese Zahl liegt. ECN wird für Unicast-Warteschlangen über Weighted Random Early Detection unterstützt, einen aktiven Queue-Management-Algorithmus, der Random Early Detection erweitert und mehrere Schwellen für eine einzelne Warteschlange definiert. Der Befehl random-detect ecn aktiviert die ECN-Markierung für die Unicast-Sendewarteschlange im Konfigurationsmodus und gibt die Warteschlangengrößen an, die als Schwellen dienen (Arista EOS 4.37.0F Quality of Service).

Latenzbasierte ECN lässt sich pro Sendewarteschlange einstellen. Das Beispiel im Handbuch besteht aus drei Zeilen: interface Ethernet 1/1 betreten, tx-queue 3 auswählen, random-detect ecn delay threshold 33 milliseconds setzen. Dieselbe Seite.

33 Millisekunden sind ein Beispiel, keine Empfehlung

Diese 33 als von Arista empfohlenen Wert zu lesen, wäre ein Lesefehler. Das Handbuch zeigt Syntax, keine für eine Arbeitslast oder ein Fabric-Design kalibrierte Zahl. Wer daraus etwas mitnehmen will, nimmt nicht die Zahl mit, sondern die Tatsache, dass solche Werte auf der Kommandozeile stehen und pro Gerät gesetzt werden.

Kommt die Schwelle zu spät, wächst die Warteschlange bis zum Verwerfen oder, wo verlustfreie Klassen eingerichtet sind, bis zum Rückstau in die Nachbarwarteschlangen. Kommt sie zu früh, drosselt der Sender, während die Fabric weit von der Sättigung entfernt ist. Beide Ausgänge sind Folge einer eingetippten Zahl, nicht eines Charakterzugs des Chips.

Die Anmerkung (Arad/Jericho)

In der Dokumentation erscheint der Befehl als random-detect ecn (Arad/Jericho), mit der Plattformfamilie daneben. Syntax und Verhalten hängen also am Switch-Silizium und sind nicht über die gesamte Produktlinie gleich. Dass der Hersteller selbst so schreibt, zeigt, wo die Arbeit für eine einheitliche Fabric landet.

In einem großen KI-Cluster bleibt eine einzige Chip-Generation nicht immer erhalten. Beschaffungen zu verschiedenen Zeitpunkten mischen Generationen. Dann beantwortet nicht das Datenblatt des Herstellers die Frage, ob dieselben „33 Millisekunden“ überall dasselbe bedeuten. Die Antwort steht im Konfigurationsregister des Betreibers.

Ein schnellerer Port nimmt die Konfiguration nicht mit

Eine breitere Leitung liefert Pakete schneller in dieselbe Warteschlange. Die Warteschlange füllt sich rascher, doch die Stelle, an der die Markierung beginnt, bewegt sich nicht von selbst. Der Wechsel von 400G auf 800G schreibt die Zahl hinter random-detect ecn delay threshold nicht um.

Genau hier rutscht die Debatte über KI-Backends üblicherweise ab. Portgeschwindigkeit und Optikmodul stehen in der Beschaffungsliste, werden verglichen und freigegeben. Die Markierungsschwelle pro Warteschlange steht dort nicht. Sie entscheidet trotzdem, wie sich die Fabric verhält, wenn es eng wird.

Die Grenze der Belege

Die technischen Aussagen dieses Artikels beschränken sich auf zwei als Text gelesene Primärquellen: die Seite Quality of Service zu Arista EOS 4.37.0F und RFC 3168.

Die Seiten zu Priority Flow Control, Traffic Management und AI networking lieferten in dieser Prüfung keinen lesbaren Text. Deshalb wird nichts ausgesagt über die Syntax von No-Drop-Prioritäten, über Verhalten oder Auslöser eines Pause-Watchdogs, über die Abhängigkeit von Pause-Schwellen und Headroom von Portgeschwindigkeit, Kabellänge oder Switch-Familie, über die Konfigurierbarkeit von Pufferzuteilung pro Warteschlange oder gemeinsamer Pufferreservierung, über Topologie-Vorgaben für GPU-Backend-Fabrics und über validierte Profile. Dass die Lektüre nicht gelang, ist kein Beleg dafür, dass es diese Dinge nicht gibt.

Die Unternehmensangaben zu Arista Networks, Inc. stehen im Verzeichniseintrag.