From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 CCB593B25E for ; Tue, 10 May 2016 00:04:56 -0400 (EDT) Received: by mail-ob0-x232.google.com with SMTP id aq1so345292obc.3 for ; Mon, 09 May 2016 21:04:56 -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=eD8eRuIoRvDiylFbvAv8zsWkk1XLbD4uesTT/eHpPS4=; b=kRZd5StdqOH7UTvhQ/8PSt+PoCbEL2gFVmEM7K83HatJrXPYpBMEMSmdStMc4UYSFN ShWoSL+SZchuiQoOf5FW6Ovi/8tRaDdYxaiFo9RE3OA/v5Gu+OpgcNI7FKG+oHrj8WA2 lb5CdY+YJ356rdK3ekYMYalkLeQD6d5zeB7sMj4fpNXh/B+r142RawT5D+cLyQ2ogtZ2 hGySUNZgMNp0jV1CVF5HcaupOVR4y2zBwMksC4PBPUSazLB7Z827os3/jqKSplYq/pLa eDvDY3UCJ+my/t6sJxCarFbEugvDAt6nhBGfWiMsurEgfEwnuI46RpFhGMaH+8TOfPlM TmwA== 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=eD8eRuIoRvDiylFbvAv8zsWkk1XLbD4uesTT/eHpPS4=; b=WCE9cWS5q6WwujKxaaYvmUC15l9VSiTvPoWknisWVtboNqU4SDkAXD/toRfCgYhQkY uAYriMSjfov6WjpVBvf0/iRX7K4id4phh2VyhvUS2XygMW+Tu+H7AVkyAyXV3iN24mMO iYafJbtAA4GKQyfmVAtt8z3QSVjdoAa/7rjl+YsXQYyN2YXH7fpku5E5srE1iNjJRqE2 H5jWgrLrFfDFG5wJNhzV1nCZ5zqDNEAxEknCrFSzKL3HPUvx1KDv8dvOGl5EY/gwj6Kr 4rz9TPkbEHdDlYnSbLUW9kKavjA1F9j63n4RKfLzi+qorpaPRQ0FPgE/m9BIkHhMEyBT 7T3Q== X-Gm-Message-State: AOPr4FVOxnYeTcDttd03UhYpD0MwtULbxi5k9XHDqEbc1IMtPEI7J4qdeXdLENMhlShEg307UOIGc2FZFk4kPg== MIME-Version: 1.0 X-Received: by 10.182.2.6 with SMTP id 6mr17628971obq.26.1462853096036; Mon, 09 May 2016 21:04:56 -0700 (PDT) Received: by 10.202.229.210 with HTTP; Mon, 9 May 2016 21:04:55 -0700 (PDT) In-Reply-To: References: <871t5bpkc7.fsf@toke.dk> <6ADC1A9D-72C9-47A5-BDC7-94C14ED34379@gmail.com> Date: Mon, 9 May 2016 21:04:55 -0700 Message-ID: From: Dave Taht To: Adrian Chadd Cc: Jonathan Morton , make-wifi-fast@lists.bufferbloat.net, "ath9k-devel@lists.ath9k.org" , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [ath9k-devel] 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 04:04:56 -0000 On Mon, May 9, 2016 at 8:30 PM, Adrian Chadd wrote: > Hi, > > So: > > * the hardware can give us a per-AC transmit opportunity; > * software queuing needs to handle the per-STA transmit opportunity; > * they (and I followed convention after testing) "They" had probably not made proper sacrifices to the layer 3 congestion control gods, nor envisioned a world with 10s of stations on a given ap and dozens of competing APs.... > found the "best" > compromise was to hardware queue up to two frames, which we could > probably do slightly more of at higher MCS rates for "reasons", but if > we're getting enough packets come in then if the hardware queues get > drained slower than we can fill them, we naturally aggregate traffic. > > So it actually works pretty well in practice. Aside from seconds of queuing on top. :) Is everybody here on board with reducing that by 2 orders of magnitude? I'm not posting all these results and all the flent data just to amuse myself... The size of the potential patch set for softmac devices has declined considerably - codel.h and the fq code are now generalized in some tree or another, and what's left is in two competing patches under test... one that leverages rate control stats and wins like crazy, the other, dql, and takes longer to win like crazy. http://blog.cerowrt.org/post/ has the writeups https://github.com/dtaht/blog-cerowrt has all the data and the writeups still in draft form, in git, for your own bemusement and data comparisons with the stock drivers. > The general aim is to > keep up to ~8ms of aggregates queued, and that's typically two > aggregate frames so we don't bust the block-ack window. My understanding was that hardware retry exists for the ath9k at least, and that block-acks responded in under 10us. Also that ath9k allowed you to describe and send up to 4 chains at different rates. Yes? As for "busting the window", what I wanted to try was adding in QoS Noack on frames that you feel could be safely dropped, so the first part of the txop would have an AMPDU of stuff you felt strongly about keeping, the second, one not block acknowledged, and a third consisting of the last bits of the flows you didn't care about as much, but want to provide packets for to inform the other side that drops happened, block acked.... As for software retry, we could be smarter about it than we currently are. A fixed number of retries (15 in the ath10k driver, 10 in the ath9k driver) is just nuts... As for 8ms, well, I'd much rather hand out 1ms each to 8 stations than 8ms each to 8 stations. > > > -adrian --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org