From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 9E5963B25E for ; Mon, 9 May 2016 22:59:04 -0400 (EDT) Received: by mail-oi0-x22a.google.com with SMTP id k142so233160328oib.1 for ; Mon, 09 May 2016 19:59:04 -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=eZv6eyblIKQcgWro1KQ7KjRT9bLhBApAL0HIjLyHIS0=; b=wpmjDSaB4KlgNDNdxV+LdNoPakNspqnieAs9BWlE8YnwEZypXj0x9x77AUYGV6S+J3 o/ghYmibpgvGigeeJz8bkNEqcAChRrYtLab7yClCkVOSONfB4kV9swb3PWeskvPZlon/ jNNN//O+agWoBXIZhwZ7j32P+evn8PPLhDBW9+p2VHnGnAytYwX2WBofQ8XzW3M9llim eFd0YeGtcquk8ht/4Y6TnVz2n4XgvSRDPhBu6HQxvJ8eLKxP0NYndwbKbies+vNzkke0 rEEyvy4AyOmtUi72LtdhlRaf3gBA6b1SSBwMvcDUMV6SeZIyX3mme++nVaGqRCFKNj0p jOFw== 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=eZv6eyblIKQcgWro1KQ7KjRT9bLhBApAL0HIjLyHIS0=; b=Snd42/jzv1dkZh8pP7i1X8hOw3y4XwThgYJRyR6pCJdSkxYERL6uz3JXXyTxJTy2rq ll8ug3aNgg4hCjd1Rr5immeJYLlMXk1H4Lp36PUpUX9O1vgbFpBAsZeoz3pJZScnJ09y wDtB1wy/+krtNgH5b9hg07P4UXETQ0q3qZ9Oul1Qey6cQq4GBdvIPa8j96AakACeVQ+p Q0tI7Zj4QhiVHOIheFAHO4Ur2Td/+u3oe7x0A7hJPKSTNxkGhyI5JxWFHgriVOt5dPWC oiLjQ0jL+lMwvWqRzaErX/5q3ICwLV3atk+z4qOlmIUlTGWDA6cocEda7k/xpYYj89nk Qi4Q== X-Gm-Message-State: AOPr4FVWwIHwAd0g5qBYMIAasdnzVEpNhnHmoIPVEqwNfWz7oYxAHFOR5VTnSvBwGzATAb0XAQq7tlMiSwFu/g== MIME-Version: 1.0 X-Received: by 10.157.4.174 with SMTP id 43mr1520792otm.127.1462849144000; Mon, 09 May 2016 19:59:04 -0700 (PDT) Received: by 10.202.229.210 with HTTP; Mon, 9 May 2016 19:59:03 -0700 (PDT) In-Reply-To: <6ADC1A9D-72C9-47A5-BDC7-94C14ED34379@gmail.com> References: <871t5bpkc7.fsf@toke.dk> <6ADC1A9D-72C9-47A5-BDC7-94C14ED34379@gmail.com> Date: Mon, 9 May 2016 19:59:03 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , make-wifi-fast@lists.bufferbloat.net, "ath9k-devel@lists.ath9k.org" 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: Tue, 10 May 2016 02:59:04 -0000 On Mon, May 9, 2016 at 7:25 PM, Jonathan Morton wro= te: > >> On 9 May, 2016, at 18:35, Dave Taht wrote: >> >> should we always wait a little bit to see if we can form an aggregate? > > I thought the consensus on this front was =E2=80=9Cno=E2=80=9D, as long a= s we=E2=80=99re making the decision when we have an immediate transmit oppo= rtunity. I think it is more nuanced than how david lang has presented it. We haven't argued the finer points just yet - merely seeing 12-20ms latency across the entire 6-300mbit range I've tested thus has been a joy, and I'd like to at least think about ways to cut another order of magnitude off of that while making better use of packing the medium. http://blog.cerowrt.org/post/anomolies_thus_far/ So... I don't think we "achieved consensus", I just faded... I thought at the time that merely getting down from 2+seconds to 20ms induced latency was vastly more important :), and I didn't want to belabor the point until we had some solid results. I'll still settle for "1 agg in the hardware, 1 agg in the driver"... but smaller, and better formed, aggs under contention - which might sometimes involve a pause for a hundred usec to gather up more, when empty, or more, when the driver is known to be busy. ... Over the weekend I did some experiments setting the beacon advertised txop size for best effort traffic to 94 (same size as the vi queue that was so busted in earlier tests ( http://blog.cerowrt.org/post/cs5_lockout/ ) ) to try to see if the station (or AP) paid attention to it... it was remarkable the bandwidth symmetry I got compared to the defaults. This chart also shows the size of the win against the stock ath10k firmware and driver in terms of latency, and not having flows collapse... http://blog.cerowrt.org/flent/txop_94/rtt_fairbe_compared.svg Now, given then most people use wifi asymmetrically, perhaps there are fewer use cases for when the AP and station work more symmetrically, but this was a pretty result. http://blog.cerowrt.org/flent/dual-txop-94/up_down_vastly_better.svg Haven't finished writing up the result, aside from tweaking this parameter had no seeming affect on the baseline 10-15ms driver latency left in it, under load. > > If we *don=E2=80=99t* have an immediate transmit opportunity, then we *mu= st* wait regardless, and maybe some other packets will arrive which can the= n be aggregated. > > - Jonathan Morton > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org