On Wed, Sep 21, 2016 at 1:59 PM, Phineas Gage <[email protected]> wrote: > 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?
Yes, it is effective to a small extent. However, I would highly recommend that you look into make-wifi-fast, and start testing the firmware that Toke uploaded. See this: http://blog.cerowrt.org/post/crypto_fq_bug/ (Personally, I would still prefer cables for point to point, but with the recent efforts of make-wifi-fast, this could change by next year) > > 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? > Guaranteed speed, or at least minimum guaranteed speed for both upload and download is a good idea. You don't have to login and tweak each time. > 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 this: > > LAN <=> Linux bridge with fq_codel <=> ADSL Modem 0.4 / 5.0 Mbps <=> DSLAM … I have a similar configuration: LAN <=> fq_codel (tp-link archer c7 v2 with pppoe) <=> FTTH modem (bridge mode) May I ask why put the ADSL modem in bridge mode, and let the fq_codel box handle pppoe ? > > 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: > Does EdgeRouter X also implement BQL for its network drivers ? > 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 > [email protected] > https://lists.bufferbloat.net/listinfo/codel > _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
