[WLANnews] Optimierung der Bandbreitenverteilung/Latenz mit fq_codel

[Ruben Kelevra]

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.

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.

Bei einem schnellen Blick auf den Quellcode von fq_codel kann ich
weder das eine noch andere belegen.


LG Ruben


2013/8/25 Felix Fietkau <nbd at openwrt.org>:
> On 2013-08-25 5:24 PM, Ruben Kelevra wrote:
>> Das hier klingt anders:
>>
>> "However, today's Linux implementation of CoDel is imperfect: there
>> are typically (at least) one or more packets of buffering under the
>> Linux qdisc, in the device driver (or one packet in htb) even if BQL
>> is available. This means that the "head drop" of CoDel's design is not
>> actually a true head drop, but several packets back in in the actual
>> queue (since there is no packet loss at the device driver interface),
>> and that CoDel's square root computation is not exactly correct. These
>> effects are vanishingly small at 1Gbps or higher, but when used at low
>> speeds, even one packet of buffering is very significant; today's
>> fq_codel and codel qdiscs do not try to compensate for what can be
>> significant sojourn time of these packets at low bandwidth. So you
>> might have to "tune" the qdiscs in ways (e.g. the target) that in
>> principle the CoDel algorithm should not require when used at low
>> bandwidths. We hope to get this all straightened out someday soon, but
>> knowing exactly how much buffering is under a qdisc is currently
>> difficult and it isn't clear when this will happen.
>>
>> When running it at 1GigE and lower, today it helps to change a few
>> parameters given limitations in today's Linux implementation and
>> underlying device drivers."
>>
>> Quelle:
>>
>> http://www.bufferbloat.net/projects/codel/wiki/Best_Practices_for_Benchmarking_CoDel_and_FQ_CoDel
> Das passt doch mit dem zusammen wovon ich gesprochen habe. Die Queue von
> der in dem Absatz die Rede ist, ist die Hardware-Queue (*under* Linux
> qdisc, nicht 'in').
> Diese Hardware-Queue wird von der txqueuelen nicht beeinflusst. Die
> txqueuelen bezieht sich auf die maximale qdisc Queue Länge.
>
> - Felix
>