[WLANnews] Optimierung der Bandbreitenverteilung/Latenz mit fq_codel

[Ruben Kelevra]

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.

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).

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.

Alternative ist BQL, wo mir unbekannt ist ob die Treiber für Ath9k
schon ordentlich funktionieren.

"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
ethtool -G wlan0 tx 4

But many can get to 20 or below."

Link: http://www.bufferbloat.net/projects/bloat/wiki/Linux_Tips


LG Ruben

Am 26. August 2013 02:53 schrieb Ruben Kelevra <cyrond at gmail.com>:
> Also in unserer Firmware ist fq_codel nicht Standard, das mag irgendwo
> im trunk der Fall sein, wäre ja auch schon Schritt in die richtige
> Richtung. :)
>
> Die Frage ist ob mein Aufbau wie oben im ersten Beitrag skizziert eine
> faire Verteilung der Bandbreite auf alle Nutzer ermöglicht... könntest
> du dir das mal anschauen? Zusätzlich hätten wir sicher auch gerne die
> Vorteile von fq_codel was den Verbindungsaufbau angeht und die
> Bandbreitenverteilung auf die Verbindungen... aber ich nehme an in
> einem Freifunk ist das eher zweitrangig, immerhin hat pfifo_fast
> bisher ziehmlich gut funktioniert.
>
> Danke für die Hilfe!
>
>
> LG Ruben
>
> Am 26. August 2013 02:22 schrieb Felix Fietkau <nbd at openwrt.org>:
>> On 2013-08-25 6:56 PM, Ruben Kelevra wrote:
>>> Ich les das irgendwie anders, hier gehts doch darum das fq_codel die
>>> Pakete an den Layer darunter weiter gibt, die txqueue von Linux und
>>> dort die Pakete nicht direkt raus gesendet werden sondern eben wieder
>>> gepuffert werden. Da fq_codel diese Pakete NICHT weiter verfolgen kann
>>> kann es sie dort auch nicht verwerfen.
>> Ich glaube du verwechselst da was - die qdisc (in diesem Fall fq_codel)
>> kümmert sich um die netdev Queue, hat also sehr wohl die Kontrolle über
>> diesen Puffer. Die txqueuelen Einstellung bezieht sich definitiv *NICHT*
>> auf die Hardware Queue Length.
>>
>> Auf die Hardware-Queue wirkt sich keine Einstellung von ifconfig aus.
>> Bei manchen Ethernet-Treibern kann die per ethtool konfiguriert werden,
>> bei WLAN ist da momentan noch nicht viel was man machen kann. Ich hab
>> einen per-WMM-AC Parameter für die Hardware Queue Length ins debugfs
>> gepackt, aber ein zu niedriger Wert dort macht schnell mal Aggregation
>> kaputt.
>>
>>> Das Problem mit hohen Geschwindigkeiten ist nun der Overhead der in
>>> fq_codel beim heraussuchen des nächsten Paketes entsteht und die damit
>>> verbundene Latenz muss in einem Puffer aufgefangen werden. Damit das
>>> Gerät immer was zum Senden vorliegen hat und nicht herumidelt obwohl
>>> etwas in der fq_codel-Queue zum Versenden ist.
>> Ich behaupte einfach mal (aufgrund von eigenen Erfahrungen, und weil
>> fq_codel inzwischen in OpenWrt default für *alle* netdevs ist), dass die
>> Extra-Latenz für den Flow Lookup nur in ganz wenigen Fällen unter hoher
>> CPU-Last überhaupt relevant ist - und da wirkt sie sich eher im <1ms
>> Bereich aus...
>>
>>> Bei einem schnellen Blick auf den Quellcode von fq_codel kann ich
>>> weder das eine noch andere belegen.
>> Ohne einen Überblick über die Größenordnungen der Latenzen der einzelnen
>> Queueing-Mechanismen zu haben solltest du lieber keine voreiligen
>> Schlüsse ziehen...
>>
>> - Felix