From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9DA6B3B2A4 for ; Mon, 16 Oct 2017 15:56:42 -0400 (EDT) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 3029621425; Mon, 16 Oct 2017 19:56:41 +0000 (UTC) From: Dave Taht To: Pete Heist Cc: make-wifi-fast@lists.bufferbloat.net References: Date: Mon, 16 Oct 2017 12:56:39 -0700 In-Reply-To: (Pete Heist's message of "Mon, 16 Oct 2017 20:28:13 +0200") Message-ID: <87mv4qrhmw.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] less latency, more filling... for wifi 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: Mon, 16 Oct 2017 19:56:42 -0000 Pete Heist writes: >> On Oct 9, 2017, at 1:13 PM, Dave Taht wrote: >>=20 >> * Less buffering at the driver. >>=20 >> Presently (ath9k) there are two-three aggregates stacked up at the drive= r. >>=20 >> With a good estimate for how long it will take to service one, forming >> another within that deadline seems feasible, so you only need to have >> one in the hardware itself. >>=20 >> Simple example: you have data in the hardware projected to take a >> minimum of 4ms to transmit. Don't form a new aggregate and submit it >> to the hardware for 3.5ms. >>=20 >> I know full well that a "good" estimate is hard, and things like >> mu-mimo complicate things. Still, I'd like to get below 20ms of >> latency within the driver, and this is one way to get there. > > For what it=E2=80=99s worth, I=E2=80=99d love to see this. One of the few= arguments for doing > soft rate limiting with point-to-point WiFi is that it=E2=80=99s still po= ssible, when > rates are stable, to achieve lower latency under load than with the new a= th9k > driver. It would be nice to see that argument disappear. Solid... I had some hope that perhaps the powersave timing architecture could be leveraged (somehow), within the new API (somehow), to starve the ath9k driver this way (someday). > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast