[Make-wifi-fast] Scaling airtime weight in dynamic mode

Toke Høiland-Jørgensen toke at toke.dk
Tue Sep 7 15:40:16 EDT 2021

Joachim Bodensohn via Make-wifi-fast
<make-wifi-fast at lists.bufferbloat.net> writes:

> Hello there, 
> we did some tests with airtime scheduling in dynamic mode and found,
> that dynamically calculated weights (256, 512, 768, ..) had no effect
> upon airtime scheduling and resulting traffic throughput.
> The issue seems to be similar as reported by
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2020-September/002933.html
> , because when we made tests with static mode, we had to scale weights
> to higher values e.g., 45000 and 15000 and set AQL threshold of 5000
> and limits per AC 0/5000 to observe the expected outcome.
> It seems, that one need some scaling factor in dynamic mode, which
> scales the results of the dynamic weight calculations to higher
> values. Does someone have any idea on how to solve this problem e.g.,
> by scaling the dynamically calculated weights to appropriate values in
> dynamic mode?

AFAICT you're running TCP-based tests, right? What usually happens with
TCP is that the queues oscillate between full and empty, which means
that the AP often only has a single station that's backlogged, which
doesn't give it a lot to enforce fairness between.

I *think* that the reason it works to scale up all the weights is that
it basically corresponds to raising the quantum of the round-robin
scheduler, so it spins longer before it lets a station transmit (thus
giving queues time to fill up).

And the lowering of the AQL threshold pushes the queues up into the
stack from the firmware, also giving the scheduler more to push back on.
With the settings you quoted, you're basically setting a total limit for
the interface of 5 ms of airtime outstanding. I'd be interested in
hearing whether you have see any ill effects on total throughput when
doing this (disregarding any fairness settings)?

As for the test itself, it would be great if you could try it on a 5.14
kernel as well. We reworked how the fairness scheduler works there, in
this commit:


The result of this is that there's no longer a round-robin scheduler to
increase the quantum of, so I don't think the scaling of the weights
will make much difference. On the other hand, it also uses a time-based
notion of when a station was last active, which may help resolve your
initial issue without any scaling applied...


More information about the Make-wifi-fast mailing list