From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8E1C521FDBF; Sat, 8 Aug 2015 07:25:17 -0700 (PDT) Received: from mobile-166-171-251-124.mycingular.net ([166.171.251.124] helo=[10.39.172.61]) by masada.superduper.net with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:128) (Exim 4.80) (envelope-from ) id 1ZO53c-0003ca-H1; Sat, 08 Aug 2015 15:25:12 +0100 From: Simon Barber To: Rich Brown , Jonathan Morton Date: Sat, 08 Aug 2015 07:25:04 -0700 Message-ID: <14f0db33ed8.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> In-Reply-To: <4DB19372-E89D-4153-B8DC-999555FE0363@gmail.com> References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> <4D24A497-5784-493D-B409-F704804326A7@gmx.de> <1438361254.45977158@apps.rackspace.com> <6E08E48D-5D53-48E5-B088-2D1DB5E566AD@gmail.com> <4DB19372-E89D-4153-B8DC-999555FE0363@gmail.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.29 (build: 21070094) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.9 (--) Cc: make-wifi-fast@lists.bufferbloat.net, dpreed@reed.com, cerowrt-devel@lists.bufferbloat.net, Mikael Abrahamsson Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 14:25:46 -0000 Some level of hardware queueing is necessary to meet the response time. It's further complicated by the need to include retries at the start of the next aggregate, but you only learn which ones from the block-ACK received after the last one. Given the hardware's need to have frame length well before the data you may have only a few microseconds to make some decisions. This is why all recent chipsets have a fairly fast CPU on board dedicated to implementing some of these functions. Of course the quality of the design and implementation varies hugely from vendor to vendor, and the API in terms of queueing varies. Simon Sent with AquaMail for Android http://www.aqua-mail.com On August 7, 2015 10:36:04 AM Rich Brown wrote: > Ah..., the bitter bit of the reality sandwich. Yum :-( > > But Dave's note about Felix's hook for per-station queueing makes it seem > feasible, if only a lot of work. > > Thanks, all, for the enlightenment! > > Rich > > On Aug 7, 2015, at 9:28 AM, Jonathan Morton wrote: > > > > >> On 7 Aug, 2015, at 15:22, Rich Brown wrote: > >> > >> - At that time, the wifi driver requests packets from fq_codel until a) > the the fq_codel queues are empty, or b) the wifi frame is full. In either > case, the wifi driver sends what it has. > > > > There’s one big flaw with this: if packets are available for multiple > destinations, fq_codel will generally give you a variety pack of packets > for each of them. But a wifi TXOP is for a single destination, so only > some of the packets would be eligible for the same aggregate frame. > > > > So what’s needed is a way for the wifi driver to tell the queue that it > wants packets for the *same* destination as it’s transmitting to. > > > >> - Once the transmit opportunity has come around, it's a matter of > microseconds (I assume) to pull in a wifi frame's worth of packets from > fq_codel > > > > This is hard to guarantee in software in a general-purpose OS. > > > > - Jonathan Morton > > > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast