Re: [Codel] Using fq_codel with a WiFi uplink to the Internet

[Loganaden Velvindron <loganaden@gmail.com>]

On Wed, Sep 21, 2016 at 1:59 PM, Phineas Gage <phineas919@gmail.com> 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
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>