[WLANnews] Optimierung der Bandbreitenverteilung/Latenz mit fq_codel

[Ruben Kelevra]

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