Kernel-Log – Was 3.2 bringt (1): Netzwerk
Der TCP-Stack passt die Datenrate jetzt schneller an die Leitungskapazität an. Die Treiber für einige WLAN-Bausteine von Atheros und Broadcom sind erheblich gereift; andere Treiber unterstützen ab 3.2 mehr LAN- und WLAN-Hardware als zuvor.
- Thorsten Leemhuis
Nach der Freigabe der ersten Vorabversion von Linux 3.2 und dem damit beendeten Merge Window flossen keine größeren Änderungen mehr in den Hauptentwicklungszweig von Linux ein. In Kürze dürfte Linus Torvalds vermutlich den zweiten RC der Anfang bis Mitte Januar erwarteten Kernel-Version freigegeben; wie schon in den vergangenen Tagen nimmt er bis dahin vornehmlich Korrekturen und kleine, ungefährliche Verbesserungen auf.
Das Kernel-Log kann daher bereits jetzt einen umfassenden Überblick über die wichtigsten Neuerungen von Linux 3.2 bieten. Der erfolgt wie gewohnt mit einer Artikelserie "Was 3.2 bringt", die sich den unterschiedlichen Funktionsbereichen des Kernels annimmt. Den Anfang der Serie macht die folgende Beschreibung der wichtigsten Änderungen am Netzwerk-Stack und an den Treibern für LAN- oder WLAN-Hardware. In den kommenden Wochen folgen Artikel zu Storage, Dateisystemen, Architektur-Code, Infrastruktur sowie zu Treibern für sonstige Hardware.
Kapazitätsanpassung
Die Kernel-Entwickler haben den TCP-Stack von Linux 3.2 um Unterstützung für "Proportional Rate Reduction" (PRR) erweitert. Der von einem Google-Mitarbeiter eingebrachte und einem IETF Draft beschriebene Algorithmus soll die Sendegeschwindigkeit besser an die Kapazität anpassen, welche die Gegenstelle und die auf dem Weg dorthin passierten Router verarbeiten können; speziell nach einer Drosselung aufgrund drohender Überlastung soll der Algorithmus auf der Sendeseite wieder schneller zur maximalen Transferrate hochschalten als der bisher genutzte Ansatz, den RFC 3517 ("A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP") beschreibt.
Laut Messungen des Entwicklers soll der Algorithmus die HTTP-Antwortzeiten um drei bis zehn Prozent reduzieren. Details zur Arbeitsweise liefern der Commit-Kommentar, ein LWN.net-Artikel, ein Paper zum Thema sowie PDF-Dokumente von zwei IETF-Präsentationen (1, 2).
Reifeprozess
In der zeitweise etwas verfahrenen Situation um zwei Treiber für neuere WLAN-Chips von Broadcom haben die von Broadcom selbst vorangetriebenen Brcm80211-Treiber Brcmsmac und Brcmfmac jetzt das Rennen gemacht und zogen in das Netzwerk-Subsystem ein. Der vor über einem Jahr veröffentlichte Treibercode wurde bislang im Staging-Bereich gepflegt, wo Code liegt, der den Qualitätsansprüchen seiner Entwickler oder der Kernel-Hacker nicht genügt; einzelne Distributionen lassen Staging-Treiber daher außen vor.
Die meisten Mängel haben die Broadcom-Entwickler im vergangenen Jahr unter Anleitung erfahrener Kernel-Entwickler beseitigt. Der schon länger im Kernel enthaltene B43-Treiber, der auch ältere WLAN-Chips von Broadcom anspricht, unterstützt fürs Erste weiter einige der WLAN-Bausteine, welche auch die Brcm80211-Treiber ansprechen; vermutlich wird der Kernel langfristig aber letztgenannte Treiber bevorzugen. Wer die Brcm80211-Treiber nutzen will, darf derzeit allerdings den Treiber Bcma nicht einkonfigurieren, auf den B43 zum Zugriff auf einige der neueren WLAN-Bausteine von Broadcom angewiesen ist.
In das Netzwerk-Subsystem zog auch der WLAN-Treiber Ath6kl für den AR6003 von Atheros ein. Er basiert auf dem gleichnamigen Staging-Treiber, der parallel entfernt wurde. Die verbesserte und dabei erheblich geschrumpfte Version des Treibers wurde unabhängig vom Staging-Bereich entwickelt; sie ist erheblich kleiner und beherrscht laut Commit-Kommentar nicht alle Funktionen, die der Staging-Treiber bot.
Die teils umfangreichen Aufräumarbeiten an den beiden Treibern und ihre Umzüge sind mitverantwortlich für die große Zahl neuer und entfernter Zeilen Quellcode, die ein Diffstat für Linux 3.2 ausweist. Dazu beigetragen hat auch der Austausch des Staging-WLAN-Treibers Rtl8192e gegen eine erheblich überarbeitete Code-Variante, die zwar noch Mängel aufweist, aber deutlich bessere Chancen hat, irgendwann vom Staging-Bereich in das Netzwerk-Subsystem umzuziehen (u. a. 1, 2, 3).
