[WLANnews] Optimierung der Bandbreitenverteilung/Latenz mit fq_codel

[Felix Fietkau]

On 2013-08-29 2:44 AM, Ruben Kelevra wrote:
> Wie ich schon vermutet hab ist die txqueue hinter der qdisc, das heißt
> eine qdisc übergibt die Daten an die txqueue und dort kann die qdisc
> keinen Einfluss mehr auf sie nehmen.
Von welcher Queue redest du wenn du "die txqueue" sagst? Wenn du die
Hardware Queue meinst, dann stimmt das so. Mit der txqueuelen hat das
trotzdem nix zu tun.

> Das Problem hierbei ergibt sich bei der Nutzung von fq_codel in sofern
> das dieser Algorithmus schaut wie lange die Elemente in der Queue
> liegen um zu entscheiden ob ein Stream verlangsamt werden soll. Wenn
> nun in einer Queue schon 100 Pakete lange liegen, weil das
> WLAN-Interface sehr langsam arbeitet wird das erste Paket in der Queue
> verworfen und durch den Verlust kann der Sender die Verbindung
> drosseln, da der Empfänger meldet das dieses Paket nicht angekommen
> ist (durch Meldung die Pakete danach kamen an).
Die Queue auf die diese Problembeschreibung passt ist die
Hardware-Queue, und *nicht* die Netzwerk-Stack-Queue.

> Nun ist das Problem wenn die txqueuelen=1000 ist liegen bis zu 1000
> Pakete HINTER der qdisc, darauf hat die qdisc nun keinen Einfluss mehr
> und weiß auch nicht wie viele Pakete dort nun verweilen, in sofern
> kann der Mechanismus von fq_codel nicht greifen gewisse Paketströme zu
> verlangsamen und ein bufferbloat ist die Folge.
Ich bleibe dabei, dass diese Interpretation falsch ist, und sie wird
auch durch den Link den du gepostet hast in keinster Weise untermauert.
Außerdem, unter "Reduce transmit queue length" steht explizit:
"NOTE: with codel, this is no longer needed either."
Es wäre vom Design her relativ sinnfrei, im Netzwerkstack eine
zusätzliche Queue zu haben, die von der qdisc (Queue Discipline!) nicht
angefasst werden kann.

> Alternative ist BQL, wo mir unbekannt ist ob die Treiber für Ath9k
> schon ordentlich funktionieren.
Das Problem bei ath9k ist dass die interne Queueing-Struktur von einem
802.11n WLAN-Treiber komplexer ist als alles was man irgendwie vom
Netzwerk-Stack managen lassen kann.
Für Aggregation ist eine gewisse Menge an Buffering absolut nötig, aber
man kann im Netzwerk-Stack keine pro-Nachbar Queueing-Struktur anlegen,
mit der man unterschiedliche Queue-Längen je nach Datenrate,
Aggregation-Tiefe, etc. implementieren könnte.
BQL ist hierbei leider vom Konzept her völlig ungeeignet.
Ich arbeite bereits länger an einem Design für einen Bufferbloat-Fix für
ath9k und andere WLAN-Treiber. Dabei werde ich sämtliches
Software-Queueing vom Treiber nach mac80211 verschieben, und danach eine
fq_codel Variante in mac80211 implementieren.
Die qdisc vom Netzwerk-Stack werde ich dabei komplett außen vor lassen
und alles in mac80211 machen, bis die netdev Maintainer es geschafft
haben darin eine Queueing-Struktur zu implementieren die pro-Nachbar
Queues kann.

> "In modern devices, the dma tx queue often defaults to settings
> suitable for transmission on a pure GigE (or faster) network.
> 
> If your network has significant bottlenecks (such as a 3Mbit home
> gateway or wireless), this is the most important knob to twist to
> reduce your bufferbloat.
> 
> Once data hits the dma tx queue, it cannot be controlled or shaped. In
> many cases ethtool is not supported, however, if you can, reduce these
> buffers to the bare minimum for good performance. Few devices support
> going as low as this:
> 
> ethtool -G eth0 tx 4
Auf ar71xx Geräten gibt's schon BQL support für Ethernet, da braucht man
die DMA tx queue nicht verkleinern.

> ethtool -G wlan0 tx 4
Und auf WLAN funktioniert das ganze gar nicht erst.

- Felix