From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CCF9E3B2F7; Fri, 23 Sep 2016 14:36:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 4884A40D5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1474655782; bh=AJCkj3BdjcS54o2G7MFXfxnLFEMZs5DZXvvqdqPokZg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=qo1BF9OEGDraDPg3OOaRyw9ZY4DmaIC6E1wEg+cFfnETmfJpZ+Dedk8H1SQDMgZhJ 9WmBtf/Q7pCMP+EDVYFwSgrKBqvO+VRa36Fq6Cnl5t1e9YQ0+Ms8Yy6qESSVaiBtEB A1WcrmUuSXZ5lMPBmbnf14FVokvhszQp7y5uOwuA= Sender: toke@toke.dk Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 052BD9601; Fri, 23 Sep 2016 20:36:21 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Phineas Gage Cc: Dave Taht , make-wifi-fast@lists.bufferbloat.net, "codel\@lists.bufferbloat.net" References: <945ED215-49E0-4F56-8B9A-FA95C0A82ABE@gmail.com> <5A4FB1B4-7B2F-4E71-AA86-548C1C26181F@gmail.com> <87d1jud1cc.fsf@toke.dk> <679F5D5D-34C7-468D-9460-4D25A33D1F24@gmail.com> Date: Fri, 23 Sep 2016 20:36:20 +0200 In-Reply-To: <679F5D5D-34C7-468D-9460-4D25A33D1F24@gmail.com> (Phineas Gage's message of "Fri, 23 Sep 2016 20:11:22 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878tuibh0b.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] 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: Fri, 23 Sep 2016 18:36:26 -0000 Phineas Gage writes: > On Sep 23, 2016, at 6:31 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Phineas Gage writes: > > On Sep 21, 2016, at 12:32 PM, Dave Taht wrote: > On Wed, Sep 21, 2016 at 2:59 AM, Phineas Gage wro= te: > > Do I have any chance of running fq_codel in the driver on a Mikrotik > 911-5HnD (firmware 3.30) with Atheros AR9300? If so, I may be able to > test it. The camp will be off-season soon until next April for the > snowy Czech winter, so it=E2=80=99s a good time for testing, as I also t= est > our meshed OpenWRT APs. > > Can it run LEDE (OpenWrt)? If so, all you need to do is upgrade to > current trunk, and you'll be using the FQ-CoDel'ed driver :) > > I don=E2=80=99t know for sure, but the specs are so close to this working > board (https://wiki.openwrt.org/toh/mikrotik/rb91xg_5hpnd) that I bet > so. Secondly, I have to find out if the ISP will allow it. They will > probably be more likely to do so if the driver could run on RouterOS > 6.34.3. I=E2=80=99m guessing that=E2=80=99s not a priority right now. :) Wikipedia thinks that is based on Linux 3.3.5. Which is ancient. So no. But in principle it could be done... > Q: Would it also be useful to have fq_codel running on our APs? They > are Open Mesh OM2P HS=E2=80=99s with "Atheros AR9341 rev 1=E2=80=9D chip= s. > > Most likely, yes. You may also want to include the patches that gives > you airtime fairness on those. Keeps slow stations from slowing everyone > else down. I have a git tree with those here: > https://kau.toke.dk/git/lede/ - it's slightly behind mainline LEDE, so > you may want to use that as a base. This is the critical file, in that > case: > https://kau.toke.dk/git/lede/tree/package/kernel/mac80211/patches/347-at= h9k-Add-a-per-station-airtime-deficit-scheduler.patch > > I could add it now using =E2=80=9Ctc", but any level lower than that wou= ld > require the driver support, obviously. My feeling is that the rate > limiting on my Linux bridge puts the queues =E2=80=9Cmostly=E2=80=9D the= re, and not in > the APs or upstream devices. > > Depends on your traffic patterns, of course. But yeah, if all your > clients share the same uplink and that has more bandwidth than the > AP-to-WiFi link, then that is where the bottleneck would be. But a > client with bad reception can end up with an effective rate as low as > 6.5 Mbps, so not always. > > Well, if our uplink goes to 30 Mbps or more, I=E2=80=99ve got repeater no= des > that connect to their gateways at around that rate and fluctuate, so > we=E2=80=99re likely to be moving the bottleneck around the camp sometime= s if > our Internet rate goes up. And in this environment, I know for sure > that there are clients connecting at rates well below 30 Mbps! If > there were negative MCS indexes, we would be using those. Indeed. We still have a few kinks to work out to get CoDel to work well at all bandwidths. But it's not a huge showstopper; what we have now is still tons better than before. > Right now, the OpenWRT release we run on the APs comes from Open Mesh. > Unless I can convince them to build a driver with this patch, I=E2=80=99ll > have to build and flash my own OpenWRT and give up the use of their > online dashboard, upgrades and support. This is possible > (https://wiki.openwrt.org/toh/openmesh/om2p). Moreover, I=E2=80=99m more > likely to be able to do this on our APs than our point-to-point > Internet uplink devices, since those are owned by the ISP. Yeah, I know for a fact that the patches work on those devices; had them tested on a bunch :) > Thanks so much for these pointers and your efforts. The airtime > fairness patch also sounds fantastic. In the main season, there can be > a lot of contention in our environment at times, like when it starts > raining and everyone heads to their cabins to get online. I=E2=80=99d lov= e to > try this out and help you test, but will see if it will be feasible > for us. You're very welcome. And testing is always appreciated :) -Toke