[Make-wifi-fast] Using fq_codel with a WiFi uplink to the Internet
toke at toke.dk
Fri Sep 23 14:36:20 EDT 2016
Phineas Gage <phineas919 at gmail.com> writes:
> On Sep 23, 2016, at 6:31 PM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> 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:
> 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
> 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 :)
More information about the Make-wifi-fast