[Codel] Using fq_codel with a WiFi uplink to the Internet

[Toke Høiland-Jørgensen]

Phineas Gage <phineas919 at gmail.com> writes:

>  On Sep 21, 2016, at 12:32 PM, Dave Taht <dave.taht at gmail.com> wrote:
>  On Wed, Sep 21, 2016 at 2:59 AM, Phineas Gage <phineas919 at gmail.com> wrote:
>
>  Question #1: Is it still effective to run fq_codel on our edge router when I
>  have a WiFi uplink to the Internet, instead of a cabled connection like
>  ADSL? And related to that, is a high quality point-to-point WiFi connection
>  indistinguishable from a cabled connection as far as fq_codel is concerned?
>
>  It has, until recent developments, been helpful but not as effective
>  as we'd like.
>
>  We have two sets of code in the process of being finalized that should
>  work better
>  for a reasonably fast wifi uplink.
>
>  blog.cerowrt.org/post/fq_codel_on_ath10k/
>
>  https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html
>
> That looks grand. If I ever see it working, I think I'll be as
> emotional as the OP of the ath10k article. That is, having spent some
> time setting up an fq_codel bridge for our camp, and getting blank
> stares when I talk excitedly about what I’m doing. And yet if I turn
> fq_codel off, I hear pretty quickly, “what’s wrong with the Internet?”
>
> Do I have any chance of running fq_codel in the driver on a Mikrotik
> 911-5HnD (firmware 3.30) with Atheros AR9300? If so, I may be able to
> test it. The camp will be off-season soon until next April for the
> snowy Czech winter, so it’s a good time for testing, as I also test
> our meshed OpenWRT APs.

Can it run LEDE (OpenWrt)? If so, all you need to do is upgrade to
current trunk, and you'll be using the FQ-CoDel'ed driver :)

> Q: Would it also be useful to have fq_codel running on our APs? They
> are Open Mesh OM2P HS’s with "Atheros AR9341 rev 1” chips.

Most likely, yes. You may also want to include the patches that gives
you airtime fairness on those. Keeps slow stations from slowing everyone
else down. I have a git tree with those here:
https://kau.toke.dk/git/lede/ - it's slightly behind mainline LEDE, so
you may want to use that as a base. This is the critical file, in that
case:
https://kau.toke.dk/git/lede/tree/package/kernel/mac80211/patches/347-ath9k-Add-a-per-station-airtime-deficit-scheduler.patch

> I could add it now using “tc", but any level lower than that would
> require the driver support, obviously. My feeling is that the rate
> limiting on my Linux bridge puts the queues “mostly” there, and not in
> the APs or upstream devices.

Depends on your traffic patterns, of course. But yeah, if all your
clients share the same uplink and that has more bandwidth than the
AP-to-WiFi link, then that is where the bottleneck would be. But a
client with bad reception can end up with an effective rate as low as
6.5 Mbps, so not always.

-Toke