From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 BEEA43B25E; Wed, 21 Sep 2016 06:32:55 -0400 (EDT) Received: by mail-qk0-x236.google.com with SMTP id n185so40951107qke.1; Wed, 21 Sep 2016 03:32:55 -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=PJKXCbOBr50CdrpGWzGbJZdUVxyb6b5Nv5UpA/0vI1Y=; b=UqyCzETZ3CD6PuNLuhhtTcVUpmR6rWU55zUDsCDrMgu0gAamAf7bpo1hVWU8KP+zJ+ FY9G59Uwt5lspDWfKy3mJPidGVoHW2DIcHMt3FMIX4TqO5NlCBW0i6L+6WlD+qcGM8Ex wouQoT5GcjNRJJTiTPT4kzBXu6Lwh8x9ANhdgFezsG1XZI+7Er+REF8U/idEo/nLVQAB jCVMKffxTR32F+vX34lWdjxIAHTZ8vl3STEkbLi1bF6Sgo/Oq9K3JQ6DzB8GL+wirTAJ Ls+FFGg0KneHtXrT3Wc0hEfWIxQuiklXdKeyO5O4oTtS7xjp7RrMGYW80mdc+8rNdifU 3mpA== 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=PJKXCbOBr50CdrpGWzGbJZdUVxyb6b5Nv5UpA/0vI1Y=; b=NQUQKES67NIhv2vbEy+7nm1wFLUOxdO5CQAiXpGKHmeZYWo0ph2lJxCtvTyTwX1D83 Lu0AQ6TV4ntGArGqGVLt963CD7EWEIZhlZKCF+MQdUwpiPJwJ+JqkLyowqyrBwwghBzo FSc7GZKQ6/n3Ze1OhbSoHb08FJrf1BP0E4omudhKaQPjIvaoU+Ax0ccyKJzC2RTMPTav r/7Jbvm0JgKe+SK2GhWFA5dzlzz8Esf2BSa6U+0063p9hx2bIw9TcEqe0RWbyFDOzQqy r9vdHpTMvMQyNweQpSPteQPmvZ109ckSd86oP2dLjMz8tNHqWtI3uRKFusBfppwlWEMx In8A== X-Gm-Message-State: AE9vXwOdWmtCY53bCNbmTr+3r5to2i7Ayu0t19hfFVnphXQmCa3IDu2ZDmBx31WMEnVWq/6xt9YWCAWP9YtUQQ== X-Received: by 10.55.54.15 with SMTP id d15mr39005507qka.262.1474453975281; Wed, 21 Sep 2016 03:32:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.214 with HTTP; Wed, 21 Sep 2016 03:32:54 -0700 (PDT) In-Reply-To: <945ED215-49E0-4F56-8B9A-FA95C0A82ABE@gmail.com> References: <945ED215-49E0-4F56-8B9A-FA95C0A82ABE@gmail.com> From: Dave Taht Date: Wed, 21 Sep 2016 03:32:54 -0700 Message-ID: To: Phineas Gage , make-wifi-fast@lists.bufferbloat.net Cc: "codel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [Codel] Using fq_codel with a WiFi uplink to the Internet X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 10:32:55 -0000 On Wed, Sep 21, 2016 at 2:59 AM, 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? It has, until recent developments, been helpful but not as effective as we'd like. We have two sets of code in the process of being finalized that should work better for a reasonably fast wifi uplink. blog.cerowrt.org/post/fq_codel_on_ath10k/ https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k= .html Ideally you want to be able to run it on both sides. > 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? > > 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 > > 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: > > 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. regrettably no matter how "constant" your provider claims to hold the connection, in case of bad weather, especially, it is unlikely they can do so. > > 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? Ideally the algorithm should run very close to the wifi mac layer as per the urls I sent earlier. > > 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. Lacking control of both sides, I would go for the garunteed bandwidth and try to control it on the ethernet router, or with control of one side, rate limit inbound as per what you said and let outbound float (when the new code lands) > > Thanks for any thoughts on this. > > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org