Phineas Gage <phineas...@gmail.com> writes: > On Sep 23, 2016, at 6:31 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Phineas Gage <phineas...@gmail.com> writes: > > On Sep 21, 2016, at 12:32 PM, Dave Taht <dave.t...@gmail.com> wrote: > On Wed, Sep 21, 2016 at 2:59 AM, Phineas Gage <phineas...@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 _______________________________________________ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel