[Make-wifi-fast] [Codel] Using fq_codel with a WiFi uplink to the Internet

[Phineas Gage]

> 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 <mailto: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/ <http://blog.cerowrt.org/post/fq_codel_on_ath10k/>
> 
> https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html <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.

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.

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.

>> Option A: We can choose a maximum of 40/40 Mbit with 1:5 aggregation,
>> meaning we could get 40 Mbit, but we could also get a lot less at times (8
>> Mbit I assume), depending on other network load.
>> 
>> Option B: We can get a guaranteed bandwidth, but it costs more, so the
>> maximum throughput we can pay for would be less. We would probably choose
>> around 6/6 Mbit off-season, and 20/20 Mbit on-season, as the camp is a
>> seasonal business.
>> 
>> My feeling, assuming that the answer to Question #1 is "yes" and I can
>> effectively use fq_codel with WiFi at all, is to go with Option B, the
>> guaranteed bandwidth. That way, I could set fq_codel to a little less than
>> this bandwidth, and hopefully manage buffer bloat and do HTB prioritization
>> in the same way I do now. But it depends on the answers to my two questions,
>> is fq_codel still effective when using a WiFi uplink in general, and if so,
>> is it better to go with a guaranteed bandwidth.
> 
> Lacking control of both sides, I would go for the garunteed bandwidth
> and try to control it on the ethernet router, or with control of one
> side, rate limit inbound as per what you said and let outbound float
> (when the new code lands)

Thanks for the feedback. I only also wonder now if I should really have a BQL driver, or whether it makes a difference in this case. And also, whether I should rather be doing fq_codel on the ethernet adapter that’s internal to my Mac Mini, rather than the external USB adapter I’m using (more details on that also in my previous reply to Loganaden).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20160923/fc4cf4e5/attachment-0001.html>