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 4621F3B25E; Wed, 10 Aug 2016 17:50:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 49F3440D5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1470865804; bh=kYsJgweUQtJxlRDeJodUpYOeeak4sUrO9/Dg15UCR9k=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=hK27ZEhXxklHbuA1U60Brq7kr02c97zA0EmerWE7+je0ZUgLUpVMkt4Ozjk5x+H9s NpUtSU+R2rDJaeVnwYM9E4oTSi3NuuZ8rqEGGjxe+PxiVgtA2hejQFehSos+09Z9wO 3/502W+5abF4UPc8nblYrRNZO7ou8lr6H9M8SNmY= Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 64CE65647; Wed, 10 Aug 2016 23:50:03 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Dave Taht Cc: make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel\@lists.bufferbloat.net" , Felix Fietkau References: <76eb6a6a-2f39-3b36-d4c1-04198083c0f6@gmail.com> <87oa50acnr.fsf@toke.dk> Date: Wed, 10 Aug 2016 23:50:03 +0200 In-Reply-To: ("Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen=22's?= message of "Wed, 10 Aug 2016 22:06:39 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bn109tv8.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] [Make-wifi-fast] wifi airtime fairness patches could use eyeballs and testing X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 21:50:07 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > On 10 August 2016 21:35:40 CEST, Dave Taht wrote: >>Wow, that *is* weird. It is good to see the tcp window changing on >>this set of data (it wasn't before), and CWRs, but... hmmm... SCIENCE. >> >>Enabling ecn on both sides will rule out some potential bugs. > > Yeah, couldn't get ecn to work on the host I was using as the other endpo= int on > that test. Will try with another box that's not on quite as ancient a ker= nel. > Was also planning to disable codel (by setting a very high target) to try= to > narrow down the problem. OK, digging some more on this: I am seeing *no* drops by CoDel, and no backlog in the mac80211 softq layer either (or at most one or two packets when polling with a 1 sec interval). This is with one as well as with two flows. On my x86 testbed I see backlog building and packets getting dropped by CoDel - and can't reproduce the performance hit. So I'm wondering what the difference is. I can think of: - Another bottleneck somewhere in the system limiting things on the wndr3800. - A locking issue in the FQ mechanism preventing packets from being queued properly. - Something related to the wndr only having a single CPU. -Toke