> On Sep 23, 2016, at 6:31 PM, Toke Høiland-Jørgensen <[email protected]> wrote: > > Phineas Gage <[email protected] <mailto:[email protected]>> writes: > >> On Sep 21, 2016, at 12:32 PM, Dave Taht <[email protected]> wrote: >> On Wed, Sep 21, 2016 at 2:59 AM, Phineas Gage <[email protected]> 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 <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. :) >> 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/ <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 > > <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. 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 <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. 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.
_______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
