Re: [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Pete Heist <peteheist@gmail.com> writes:

>  On Feb 9, 2017, at 2:51 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>  Also, could the queue management code be abstracted into a separate
>  module, so it can be replaced, like a qdisc? I don’t know if the
>  disparity between hardware makes this too difficult or not…
>
>  Well it's abstracted into mac80211 so all wireless drivers can use it
>  (theoretically; right now only ath9k, ath10k and the not-yet-merged mt76
>  do). Making it more generic than that is not possible, since it's tied
>  to the mac80211 data structures. Which is kinda the point; the whole
>  problem was that a "generic layer" (the qdisc) didn't work well
>  enough...
>
> Nice. :)
>
> I’ll mention one example I noticed of the kind of adjustment that
> probably can’t be done from the qdisc layer today. On page 3 from
> http://pollere.net/Pdfdocs/noteburstymacs.pdf:
>
> "In addition to increasing the interval by the waiting delay s,
> another adjustment might be useful for certain kinds of bursty MACs.
> If the MAC is a request-and-grant type, as wifi in infrastructure
> mode, cable modems and some satellite modems, the allocation of bytes
> or packets that can be sent during each transmission slot is generally
> known at the beginning of transmission and may vary for each
> transmission slot. In that case, it MAY be useful to use that value
> instead of the MTU value to reset first_above_time_."

Yeah, we've had this issue with CoDel when the per-station WiFi rate
drops too low (this is a function of both signal quality and number of
stations). As a temporary fix, I just fiddled with the target until
CoDel stopped being too aggressive, but that is not a proper solution,
and so has not been upstreamed. I'm planning to get back around to
fixing that properly at some point... Problem is that it is not always
the case that "the allocation of bytes or packets that can be sent
during each transmission slot is generally known". For ath9k we could
get at this information at dequeue time, but for ath10k, only the
firmware knows ahead of time...

-Toke