I have two questions about using fq_codel on an edge router when the Internet 
uplink is through point-to-point WiFi:

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?

Question #2: Assuming the answer to Question #1 is an overall "yes", is 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 (5-10 simultaneous, at times). For Internet, we've been 
using ADSL with 5 Mbit download, 0.4 Mbit upload (remote area, so it’s slow). 
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 maximum, and use fq_codel, plus 
some HTB prioritization rules. It’s extremely effective at providing usable 
latency, so kudos to the fq_codel algorithm and implementation. It looks like 

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 
point-to-point WiFi uplink that could hit speeds of 30-40 Mbit symmetric (more 
on the speeds later). We have to decide on starting a contract with them. At 
the same time, I’ll be switching the bridge to a Ubiquiti EdgeRouter X, which 
has fq_codel in its kernel, but should have the same effect. It would look 
something like:

LAN <=> Ubiquiti EdgeRouter X <=> 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 transmit and 144.4 
Mbps receive, with CCQ (connection quality) at 64% transmit / 99% receive. 
First of all, I'll try to have them get that transmit CCQ up to 99% like the 
receive, to make sure it's a stable link. But I also know that the actual 
Internet throughput will be less than the link rates, and speedtest.net results 
are currently around 30-40 Mbps symmetric.

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 don’t 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 
edge router, or does it more depend on the quality of the WiFi link, where a 
high quality point-to-point WiFi uplink to a good upstream network (there’s 
another unknown) is indistinguishable from a cabled connection?

My Question #2 came from the fact that I have two options from the ISP:

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.

Thanks for any thoughts on this.
Codel mailing list

Reply via email to