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 0AFD33B2A2 for ; Wed, 11 May 2016 11:20:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1462980048; bh=7fI0oQyaoGkC1hTI/e/CpbFbOX8sahfjsIqZoCAmss4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=XZYK7/B7Tccy940IIrS47ADxMakDiLnAX60lOZIAiiS9W+m+6hweE2Rifmoa5lnsa iXc95PMJOlaUYtlsLm1x/lOl2GU4WIAzN26gkSWMN6R16drkALzTzyrK+R9UxzTLz0 AnpXg+lq/1U7dyqjPtPNL3TEPH0vMfiVcqiB5+BY= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 7B269C400C4; Wed, 11 May 2016 17:20:47 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Dave Taht Cc: make-wifi-fast@lists.bufferbloat.net References: <871t5bpkc7.fsf@toke.dk> <6ADC1A9D-72C9-47A5-BDC7-94C14ED34379@gmail.com> <87vb2mmgg5.fsf@toke.dk> <57333DCF.3050006@taht.net> Date: Wed, 11 May 2016 17:20:47 +0200 In-Reply-To: (Dave Taht's message of "Wed, 11 May 2016 08:09:51 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87vb2kk4ds.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] Diagram of the ath9k TX path 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, 11 May 2016 15:20:50 -0000 Dave Taht writes: > On Wed, May 11, 2016 at 7:12 AM, Dave T=C3=A4ht wrote: >> >> >> On 5/10/16 2:04 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>> David Lang writes: >>> >>>> There are two parts to this process >>>> >>>> 1. the tactical (do you send the pending packet immediately, or do you >>>> delay it to see if you can save airtime with aggregation) >>> >>> A colleague of mine looked into this some time ago as part of his PhD >>> thesis. This was pre-801.11n, so they were doing experiments on adding >>> aggregation to 802.11g by messing with the MTU. What they found was that >>> they actually got better results from just sending data when they had it >>> rather than waiting to see if more showed up. >> >> cat 802.11g_research/* > /dev/null > > Sorry, that was overly pithy (precoffee here). What I'd meant was that > 802.11e's assumptions as to how to do scheduling, particularly for > QoS, and how 802.11g behaved in comparison to n and later, does not > give you much of a starting point on how to address things now. > Successive standards and implementations have made certain things much > better and other things much worse. 802.11e !=3D 802.11g. I am completely ignoring 802.11e for now, and the rest of the standard is not that different between g/n/ac; it's basically different rates, encodings and interframe gaps. Which from a scheduling point of view simply means different constants. Once we have a working baseline scheduler we can think about how to behave sanely in an 802.11e world; as far as I'm concerned the right answer might just be "shut it off entirely"... :P -Toke