From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 866623B25E for ; Wed, 21 Sep 2016 06:28:15 -0400 (EDT) Received: by mail-pf0-x22f.google.com with SMTP id z123so18008435pfz.2 for ; Wed, 21 Sep 2016 03:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/arhNbvE6edbcMxMPFm99Kn2FRfyh7DWePQIvEHTQ7Q=; b=zVy+G+YERCaCU3mlxQ6enCDoFqN6x3Gx4j2Yj522p6KYwsiPQy7amRE+KmIGqXUp9+ aQc4aTlHtgUIGmXcH+Py+7/kHJej546lq8enFBn+UNsen/vEtyyvo4nITcbyoTIsv7LP wutuH/fUPU1mnZOhkDEvvHOtNnAtoJk85tc/Y1i4gaDLbapxYxX8bCcOmzfTpmtfObXh fTTuzQSGpq1S5CzGxx8qjI7fcQOZc4I3CXhVlFNMwjh8Kv1HO+yM1ooHT9eJerLmDha/ o3LmH1cE2DZs6lU0SxqCzWA9VXDS+P0xgd8HoVMvGadAJ/8ORu83YpZsgYPKrHjR35s/ PszA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/arhNbvE6edbcMxMPFm99Kn2FRfyh7DWePQIvEHTQ7Q=; b=MN5V4HMtA/AYn12eSUjN5yKqUsRdXZXYqUioVvL0G0U3z+nwiwURMseMJ0YXowcR3D PZUfzIo+y311+65GskLRvrjYTDc6t1xIpnz/1c7ykDwCUwemSH4Gfb6xe48ClH0rvL/r O6IFtK0jfbmGVAhh9PmBBf14fSnYZn1eY/rs4N3ZoElbZdJ4NvTIE1iq6zWXRZfXtGQg VCZKQ6da6C9kzHM8o9YS28yBj9KxBYrJoU6b2so9rFwLpYRtoleBsBCxgC87VyTfgjVX kuVEI2G+9Nq/QwfPbbTE92E+XZH2NNKqMRwzhFjZUJmy6h+4Ig9gqdCaybYq8Dp4nEjN PG8A== X-Gm-Message-State: AE9vXwMTr+YmdUlrw27ZHh9yfIj39UeDbFc1neIvYKSglGpZcCWFTq1gKMfvWhgT2YjIoVJsktiCEqE4IHpbag== X-Received: by 10.98.217.199 with SMTP id b68mr34455487pfl.74.1474453694696; Wed, 21 Sep 2016 03:28:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.102.70 with HTTP; Wed, 21 Sep 2016 03:28:14 -0700 (PDT) In-Reply-To: <945ED215-49E0-4F56-8B9A-FA95C0A82ABE@gmail.com> References: <945ED215-49E0-4F56-8B9A-FA95C0A82ABE@gmail.com> From: Loganaden Velvindron Date: Wed, 21 Sep 2016 14:28:14 +0400 Message-ID: To: Phineas Gage Cc: codel@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] Using fq_codel with a WiFi uplink to the Internet X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 10:28:15 -0000 On Wed, Sep 21, 2016 at 1:59 PM, Phineas Gage 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 whe= n 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 connecti= on > indistinguishable from a cabled connection as far as fq_codel is concerne= d? 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 i= t > 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 an= d > 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 Interne= t, > we've been using ADSL with 5 Mbit download, 0.4 Mbit upload (remote area,= so > it=E2=80=99s slow). The only thing that keeps it usable is running fq_cod= el on a > transparent Linux bridge that sits between the LAN and ADSL modem. On thi= s > bridge, I restrict the upload and download rate to about 85-90% of maximu= m, > and use fq_codel, plus some HTB prioritization rules. It=E2=80=99s extrem= ely > effective at providing usable latency, so kudos to the fq_codel algorithm > and implementation. It looks like this: > > LAN <=3D> Linux bridge with fq_codel <=3D> ADSL Modem 0.4 / 5.0 Mbps <=3D= > DSLAM =E2=80=A6 I have a similar configuration: LAN <=3D> fq_codel (tp-link archer c7 v2 with pppoe) <=3D> 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 symmetri= c > (more on the speeds later). We have to decide on starting a contract with > them. At the same time, I=E2=80=99ll be switching the bridge to a Ubiquit= i > 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 <=3D> Ubiquiti EdgeRouter X <=3D> WiFi Client (Mikrotik 802.11n MIMO = 2x2) > <=3D> WiFi AP from ISP =E2=80=A6 > > 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 t= he > 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=E2=80=99t understand. C= an this > aspect of the variable latency, throughput and packet transmission > characteristics of WiFi make fq_codel less effective when used in this wa= y > 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=E2=80=99s another unknown) is indistinguis= hable 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 tha= n > this bandwidth, and hopefully manage buffer bloat and do HTB prioritizati= on > in the same way I do now. But it depends on the answers to my two questio= ns, > is fq_codel still effective when using a WiFi uplink in general, and if s= o, > 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 >