Zusammenfassung

  • Bei Receive Livelock verbrauchen Empfangsinterrupts die CPU-Zeit, die Protokoll, Sendeweg oder Anwendung zum Abschluss brauchen. Die Maschine läuft, der nutzbare Durchsatz kann dennoch null werden.
  • Mogul und Ramakrishnan verbanden Interrupt als Wecksignal, Round-Robin-Polling, Callback-Quoten, frühes Verwerfen, Rückkopplung nachgelagerter Queues und ein CPU-Zeitlimit. Polling ohne Quote scheiterte ebenfalls.
  • Die Messungen stammten von einer langsamen Einprozessor-DECstation an 10-Mbit/s-Ethernet. Fünf bis zehn Pakete pro Runde waren kein universeller Tuningwert.

Die Maschine arbeitete, doch nichts kam an

Ein Interrupt lässt ein Hardwareereignis vor gewöhnlicher Arbeit laufen. Bei seltenen Ereignissen senkt das die Latenz. Unter einer Flut kann die Priorität jedoch verhindern, dass spätere Stufen die bereits aufgenommenen Pakete abschließen.

Im untersuchten 4.2BSD-Modell zog der Treiber Pakete aus dem Interface und legte sie in eine IP-Eingangsqueue. Das Protokoll lief später mit niedrigerer Priorität und konnte vom nächsten Eingang unterbrochen werden. War die Queue voll, investierte der Rechner weiter Arbeit in Pakete, die weder Anwendung noch Ausgang erreichten.

Das war kein Deadlock: Nach sinkender Last erholte sich das System. Während der Überlast konnten CPU und Interruptzähler trotzdem lebhaft wirken. Deshalb definierte die Arbeit Durchsatz am endgültigen Verbraucher, nicht am Empfangszähler.

Interruptpriorität war ein unsichtbarer Scheduler

Der normale Scheduler bestimmte diese Reihenfolge kaum. Feste Prioritätsstufen gaben dem Empfang Vorrang vor Protokoll, Sendeabschluss, Routingpflege und Benutzerprozessen.

Interrupt-Bündelung senkte Kosten und verschob die Grenze, beseitigte aber nicht die Ursache. Schnellere Aufnahme garantiert keinen Ausgangsturnus.

Der Interrupt weckt, das Polling verteilt

Der geänderte Kernel behielt Interrupts bei geringer Last. Unter Last markierte der Handler nur Arbeit, startete einen Polling-Thread und ließ weitere Interrupts maskiert.

Der Thread besuchte Empfang und Senden im Rundlauf. Jeder Callback erhielt eine Paketquote. Erst nach dem Leeren wurde der Interrupt wieder aktiviert. Ein angenommenes Paket sollte möglichst weit bis zum Abschluss laufen, statt an einer weiteren Prioritätsgrenze zu warten.

Das war ein Hybrid: Reines Polling verbraucht in Ruhe CPU und erhöht Latenz; reine Interrupts können bei Sättigung monopolisieren. Das erste Ereignis weckte, die begrenzte Runde verteilte Dauerlast.

Ohne Quote kehrte der Stillstand zurück

Ohne Quote fand der Empfangs-Callback immer ein weiteres Paket und kehrte nie zur Polling-Schleife zurück. Sendeabschlüsse liefen nicht, Deskriptoren wurden nicht frei, die Ausgangsqueue füllte sich und der Durchsatz fiel fast auf null.

Der Monopolist hatte nur den Ort gewechselt. Die Quote schuf den Turnus für den Ausgang. Fünf bis zehn Pakete waren auf dieser Hardware stabil; größere Lose sparten Pollingkosten, erhöhten aber Latenz und Verhungernsrisiko. Andere Hardware braucht andere Werte.

Früh verwerfen und auf die nächste Queue hören

Bei Überlast kann nicht jedes Paket abgeschlossen werden. Verwerfen am Interface vermeidet Aufwand für Treiber, Protokoll und Queues. Rückkopplung sagt dem Eingang, dass die nächste Stufe nicht mehr abfließt.

Mit screend stoppte der Kernel bei 75% Queuefüllung, begann bei 25% wieder und nutzte etwa eine Millisekunde als Sicherheitszeitgeber. Die Werte waren laut Autoren willkürlich. Übertragbar war der Regelkreis, nicht die Zahl.

Ein weiterer Mechanismus maß Netzwerkzyklen in Zehn-Millisekunden-Fenstern. Nach Verbrauch des Anteils pausierte der Eingang zugunsten von Anwendungen und Wartung. Lokale Bedienung wurde besser, entfernte Verbindungen litten weiter unter Verlust. CPU-Reserve erzeugt keine zusätzliche Kapazität.

Der Messwert trägt seine Bedingungen

Der Router war eine DECstation 3000/300 mit Digital UNIX V3.2, bewusst der langsamste verfügbare Alpha. Zwei unbelastete 10-Mbit/s-Ethernets waren verbunden. Jeder Versuch sendete 10.000 UDP-Pakete mit vier Byte Nutzlast; die Rate war ein Mittelwert, keine präzise Taktung.

Mit ursprünglichem Kernel und screend begann die Verschlechterung oberhalb etwa 2.000 Paketen/s, vollständiger Livelock erschien um 6.000. Ohne screend lag der Spitzenwert bei rund 4.700. Der Bericht untersagte die Extrapolation auf schnellere LANs und CPUs, prüfte kein echtes SMP und löste nicht die Auswahl wertvoller Pakete.

Heutige Linux-NAPI-Dokumentation zeigt eine verwandte Form: Interrupts planen Polling, IRQs bleiben maskiert und ein Budget begrenzt den Zyklus. Das ist ein Vergleich, kein Beweis, dass jede moderne Überlast Receive Livelock ist.

Google Research verortet Moguls Laufbahn bei DEC/Compaq WRL, HP Labs und Googles Netzwerkinfrastruktur. Die Arbeit bleibt gemeinsam mit Ramakrishnan. Ihre harte Regel lautet: Eingangsbeschäftigung ist keine Leistung, wenn am Ende nichts ankommt.

Quellen