From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5E6E921FDB0; Thu, 13 Aug 2015 15:25:29 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t7DMPRlQ018121; Thu, 13 Aug 2015 15:25:27 -0700 Date: Thu, 13 Aug 2015 15:25:27 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Jonathan Morton In-Reply-To: Message-ID: 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> <1438983998.16576420@apps.rackspace.com> <1439066765.7348311@apps.rackspace.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: make-wifi-fast@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] [Make-wifi-fast] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 22:25:52 -0000 On Fri, 14 Aug 2015, Jonathan Morton wrote: > The only mandatory form of aggregation in 'n' is of the one-checksum type, > even though other types are permitted. The overhead at the data layer is > slightly less, and checksum failure handling on receive is simpler (just > throw the whole thing out and nak it), as is handling the nak at the > transmitter (just retransmit the whole aggregate at the next opportunity). > Most 'n' hardware thus caters only to this lowest common denominator. > > I'm not sure whether soft-MAC type hardware (like ath9k) can also support > the more flexible type via driver support - I would hope so - but hard-MAC > hardware almost certainly can't be retrofitted in this way. if the ath9k driver could support this, would this cause a problem on stock clients? > However, since 'ac' hardware is required to support individual-checksum > aggregation, a dual-band 'ac' card running on 2.4 GHz will effectively be > an 'n' card with such support, even if it's a hard-MAC. right, I'm looking at what I can do to improve things even on non-ac stuff. David Lang