Note: The following two questions are not OpenWrt specific, but given the inclusion of fq_codel in OpenWrt, which has made it an important part of reducing buffer bloat on the Internet, I suspect there may be some interest in the topic.
Question #1: Is it still effective to run fq_codel on an intermediate router when I have a WiFi uplink to the Internet, instead of a cabled connection like ADSL?
Question #2: Assuming the answer to Question #1 is "yes", isn't it then better to have a guaranteed speed from the ISP, instead of having a variable but potentially higher speed, so that I can control the queue and have fq_codel and HTB prioritization work effectively?
Background:
I manage the network for a camp / conference center that supports up to about 120 users (up to 5-10 simultaneous, at times). For Internet, we've been using ADSL with 5 Mbit download, 0.4 Mbit upload (yeah, I know it's slow), and the only thing that keeps it usable is running fq_codel on a transparent Linux bridge that sits between the LAN and ADSL modem. On this bridge, I restrict the upload and download rate to about 85-90% of the maximum numbers, and use fq_codel (plus other HTB prioritization rules), and the latency at least is much better. It looks like this:
LAN <=> Linux bridge with fq_codel <=> ADSL Modem 0.4 / 5.0 Mbps <=> DSLAM ...
But now, we have a chance to improve our throughput problem by switching to a long-range WiFi uplink that could hit speeds of 30-40 Mbit symmetric (more on the speeds later). It would look something like:
LAN <=> Linux bridge with fq_codel <=> WiFi Client (Mikrotik 802.11n MIMO 2x2) <=> WiFi AP from ISP ...
We already have a test setup in place. The link rate to the ISP's AP, as reported by Mikrotik's admin console, is currently 86.6 Mbps Tx and 144.4 Mbps Rx, with CCQ (connection quality) at 64% Tx / 99% Rx. First of all, I'll try to have them get that Tx CCQ up to 90+ % like the Tx, to make sure it's a stable link. But I also know that the actual throughput will be less than that, and speedtest.net results are currently around 30-40 Mbps.
Moreover, it's WiFi, and that led to my Question #1. I know that latency and throughput can vary, and that there are more queues and more things happening with packet aggregation, etc that I do not understand. Can this aspect of the variable latency, throughput and packet transmission characteristics of WiFi make fq_codel less effective when used in this way on an intermediate bridge or router, or does more depend on the quality of the WiFi link?
My Question #2 came from the fact that I have two options from the ISP:
Option A:
We can choose something like 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 the conditions of their network.
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 do HTB prioritization and fq_codel at all with WiFi, 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.
Thanks for any thoughts on this.