From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 1EF903B2A3 for ; Wed, 11 May 2016 11:09:52 -0400 (EDT) Received: by mail-oi0-x22b.google.com with SMTP id x201so72382858oif.3 for ; Wed, 11 May 2016 08:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=tuHyGfJWOZmYldtXld+euOZM71TGAqrSjB++IHAAXlY=; b=xYiGrdil3tBxSPi0gLcWCemqGEf1TjpDnplAZonxRRcjBJ4ggILDEOCOrhqDw8dyTU QytmY896Lgc6dEiY54TIrnqox769ac8f8lcLJ/4PS2TJ39gYUSVF/OGhVfTS7ibcNi9Y LLoIHIF+srVYVZpNbWRNo60J42cZI/T0oJZzQRukLIqNcy3dB0/+xfUlS3CoE+xVeynz 8RfC5dpK45N8iaYfDLHC3RCTxpXmH7t0TG6AplB0+DPXj1zOnm0aFz9gE2SDb56vLXK5 tBSoGsZTx+a79fxysXRbtGBcoOArUKzcKYCE+vRIeBLcEU8oKUZPGvQGbXmLLfOqVDdL XLNw== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=tuHyGfJWOZmYldtXld+euOZM71TGAqrSjB++IHAAXlY=; b=biZP5BYrgbn7dEdD8LbI3qtJ0KlO3XFbyJPgTqrvQ3u8TTLNb49RjlFpJ8SmRLkwbf nHx9B4juvww70IS3lRHq78vaw/WYUc9sS5AvjaHx/ZmdBHUnOh4rfkhaCfpziKz5Z0i/ 6uBKE9KpcbQc+PkTYv5zu4DpE6si6R3ODauxtWRb2JC0uPImy+LY4ZTLMzU3aSvvezCw 5QmGE+YyGa7hNkcdbUe/YyVT6AGoO1CFol8M5qpW1nb1Nwb3spZkEpEPYpOATWMQ+fYK tNxxOcJMiVHmfeLkFAb1oy7bQ4/jrU+MQRgMr2LzEj9RGuqHkoP8ut4iSOnGUfsLaBW6 YWZw== X-Gm-Message-State: AOPr4FXDGYzz6OI2XOIziIDc1+zLQeG5jFdESMwLqIpwmLm5NPYWHebzg+CHVVmD3R0GP3aQqDX1I6EjUVFYvg== MIME-Version: 1.0 X-Received: by 10.157.51.29 with SMTP id f29mr2233056otc.115.1462979392189; Wed, 11 May 2016 08:09:52 -0700 (PDT) Received: by 10.202.229.210 with HTTP; Wed, 11 May 2016 08:09:51 -0700 (PDT) In-Reply-To: <57333DCF.3050006@taht.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 08:09:51 -0700 Message-ID: From: Dave Taht To: =?UTF-8?Q?Dave_T=C3=A4ht?= Cc: make-wifi-fast@lists.bufferbloat.net 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:09:53 -0000 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. Adopting 802.11e style QoS framing - good idea Adopting 802.11e style hw queue scheduling (EDCA) by mapping diffserv queues blindly to to those hw queues - horrific, without also attempting to meet the service time requirements in the software queue management. I have been perpetually demonstrating 200+ms VO queues since day one, starving the other queues, where what you want is a very short queue (under 10ms), served sparsely (say, no more than 2 or 4/10ths of the overall airtime) - and only "The right stuff" to map into it. CS6/CS7 do not belong in VO. 802.11n - It became saner to just aggregate in most cases where you might have used 802.11e qos, steering flows into the next packed txop. And as noted elsewhere[1], per station queuing so you can, indeed, aggregate sanely. Packing on all the new management frames and crypto without sanely managing those, not so good idea. Holding multicast to it's 1998 rate... grump. 802.11ac - adopting the better framing universally for all hw queues - good. Still blindly exposing those queues to userspace - horrible. Hiding most the rate control and retry information (as all firmware seem to do thus far), tying our hands behind our backs. Using up all the channels in a world with an ever increasing density of aps and stations and trying to manage the allocations in hardware, scary. Four color theorem.... Cramming up to 4MBytes into a single TXOP - what a great lab result! I have no idea how to do that, and am pretty sure even trying is undesirable. ... I'd like to (re)start with 802.11ac assumptions and work backwards, rather than 802.11g assumptions and work forwards. The most desirable thing I'd love to see is hardware capable of turning the tail end of a txop around and sending some real data back, and to know if QosNoack can be selectively used..... And on my bad days, I really would like to go back to playing with 5mhz channels (which the ath9k still supports), and getting channel selection to work better. I'd rather have 5mbits of reliable low latency bandwidth in the real world, than 500Mbits in a faraday cage. /me goes in search of some more coffee. [1] I really wanted people to argue with me about this talk one day... http://blog.cerowrt.org/post/talks/make-wifi-fast/ --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org