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

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

Phineas Gage <phineas919@gmail.com> writes:

>  On Sep 23, 2016, at 6:31 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>  Phineas Gage <phineas919@gmail.com> writes:
>
>  On Sep 21, 2016, at 12:32 PM, Dave Taht <dave.taht@gmail.com> wrote:
>  On Wed, Sep 21, 2016 at 2:59 AM, Phineas Gage <phineas919@gmail.com> wrote:
>
>  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 :)
>
> I don’t know for sure, but the specs are so close to this working
> board (https://wiki.openwrt.org/toh/mikrotik/rb91xg_5hpnd) that I bet
> so. Secondly, I have to find out if the ISP will allow it. They will
> probably be more likely to do so if the driver could run on RouterOS
> 6.34.3. I’m guessing that’s not a priority right now. :)

Wikipedia thinks that is based on Linux 3.3.5. Which is ancient. So no.
But in principle it could be done...

>  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.
>
> Well, if our uplink goes to 30 Mbps or more, I’ve got repeater nodes
> that connect to their gateways at around that rate and fluctuate, so
> we’re likely to be moving the bottleneck around the camp sometimes if
> our Internet rate goes up. And in this environment, I know for sure
> that there are clients connecting at rates well below 30 Mbps! If
> there were negative MCS indexes, we would be using those.

Indeed. We still have a few kinks to work out to get CoDel to work well
at all bandwidths. But it's not a huge showstopper; what we have now is
still tons better than before.

> Right now, the OpenWRT release we run on the APs comes from Open Mesh.
> Unless I can convince them to build a driver with this patch, I’ll
> have to build and flash my own OpenWRT and give up the use of their
> online dashboard, upgrades and support. This is possible
> (https://wiki.openwrt.org/toh/openmesh/om2p). Moreover, I’m more
> likely to be able to do this on our APs than our point-to-point
> Internet uplink devices, since those are owned by the ISP.

Yeah, I know for a fact that the patches work on those devices; had them
tested on a bunch :)

> Thanks so much for these pointers and your efforts. The airtime
> fairness patch also sounds fantastic. In the main season, there can be
> a lot of contention in our environment at times, like when it starts
> raining and everyone heads to their cabins to get online. I’d love to
> try this out and help you test, but will see if it will be feasible
> for us.

You're very welcome. And testing is always appreciated :)

-Toke