From owner-freebsd-wireless@FreeBSD.ORG Wed Sep 7 09:44:46 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 701FB1065673 for ; Wed, 7 Sep 2011 09:44:46 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id C291A8FC17 for ; Wed, 7 Sep 2011 09:44:45 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id p879iiCN063021 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 7 Sep 2011 10:44:44 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4E673D0C.7040504@unsane.co.uk> Date: Wed, 07 Sep 2011 10:44:44 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: freebsd-wireless@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [ANNOUNCE] 802.11n TX aggregation support for Atheros 11n NICs X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 09:44:46 -0000 On 07/09/2011 09:40, Adrian Chadd wrote: > Hi all, > > I apologise up front for the cross-posting. Please redirect all future > queries about this to freebsd-wireless@freebsd.org. > > I guess the cat is out of the bag (and it hasn't killed anyone yet.) > For the last 6 or so months, the if_ath driver and net80211 802.11n > support has been updated to (hopefully) be usable, both in station and > hostap modes. > Users could use ath(4) in -HEAD as an 11n station or hostap by just > disabling ampdutx. I've been doing that successfully for a few months > now at home, with respectable (> 200mbit UDP, ~ 100mbit TCP) > throughput in the receive direction (as AMPDU RX now works well.) > > Through the gracious sponsorship of Hobnob, Inc., (and the completion > of my bachelors degree in something completely unrelated to all of > this!) I've dived in head-first into the 802.11n TX aggregation > support. > > As I type this, I have an EEEPC 701 w/ an AR9280 currently spitting > out a 130mbit/sec TCP stream to a Ubiquiti Routerstation Pro MIPS > board w/ an AR9160 (5ghz HT/40/shortgi mode.) They're both running > FreeBSD. > > A user asked about the state of this code on the -wireless list a > couple days ago and has reported that his AR5416 based NIC is happily > performing much the same way. So, since it's passed my "works for > someone who isn't me!" test, I've decided to make a wider > announcement. > > There's still a -lot- to do. Specifically (this isn't an exhaustive list): > > * There are locking issues with ath/net80211 which need to be resolved > before this is merged back into -HEAD. > * There's currently no support for HT RTS/CTS frame protection. I can > add it easily enough, but I first have to add the AR5416 workarounds > (8k limitation on RTS protected frames) before I can do that. > * The AMPDU code is currently not sending BAR frames. This requires a > little more fore-thought and net80211 reorganisation before they can > be queued and sent. > * Don't try to do a UDP iperf test before you establish AMPDU, or > you'll fill the hardware TX queue with UDP frames and then end up with > no frames available to send the ADDBA management frames. Oops! :) > * The rate control module (sample) supports 11n and some basic TX > aggregation stuff, but it isn't optimal. It's only "good enough" for > me to not have to care about rate control causing large issues. > Something needs to be done before it's merged into -HEAD - either a > replacement needs to be written, or minstrel_ht needs to be ported. > * There's no hardware power saving support in place at the moment. > This means it'll draw a lot of power in station mode. > * There's no MIMO PS support. Same caveat as the above. > * adhoc, ahdemo, TDMA and IBSS modes likely won't work just yet. I'm > not likely to begin looking at those until all the net80211 and ath > driver changes are in place and tested. > * I haven't yet added "filtered frames" support, so there's going to > be a lot of packet loss in hostap mode when a station decides to go > into power-saving or off-channel mode (eg to do a scan). > * There are still (very) occasional TX-side hangs which I'm seeing. > I'm trying to get to the bottom of this. > * I've not tested this -at all- on multi-CPU/multi-core setups, > primarily because I don't run freebsd+wifi on anything like that just > yet. > * net80211 AMPDU TX is based on QoS/WME Access Category (AC) numbers, > rather than the full set of available TIDs. This is likely going to > need to change (and the ieee80211 superg support tested/updated) > before this can be merged into -HEAD as I've been told it's quite > valid to expect multiple aggregation sessions in the same AC. > > What does work (what have I tested): > > * HT/20 and HT/40 support; > * 2 and 5ghz support; > * station and and hostap modes; > * AR5416/AR5418, AR9160, AR9280 chipsets. I haven't tested AR9285 or AR9287 yet; > * HT/20 and HT/40 interoperability support - ie, a HT/40 AP can have > HT/20 and HT/40 nodes associated. 11a/11bg nodes can also associate > but the current lack of HT frame protection is likely to cause > significant interference; > * ADDBA negotiation (with the above caveat that buffer management > needs to be tidied up in my codebase, or you could end up with no TX > buffers..) > * ath_rate_sample knows enough about 11n and aggregation to make > decent enough rate choices, but it isn't optimal by any means. > * Software retransmission of aggregate frames, including doing new > rate lookups so frames aren't simply retried at a bad rate. > > What I'm currently working on: > > * verifying that AR5212 series NICs haven't been broken by this. If > someone has AR5210/AR5211 series PCMCIA hardware that they'd be able > to send to me I'll also give them a test and verify I haven't broken > them; > * fixing TX side hangs; > * HT protection support, w/ the AR5416 workarounds as needed; > * Filtered-frame support; > * More debugging and better behaviour during channel scan / off > channel behaviour and during an interface reset. > > All of that said, it's working for me and it's working for someone > else, so if you're interested in trying it out, I'm happy to take bug > reports and feedback. But since I'm still actively developing it, > please understand if I'm unable to provide you with a lot of personal > hand-holding. If you're up for picking some area of the driver (eg > porting minstrel_ht rate control, for example) then I'll be very happy > to work with you to get it tested and integrated. > > I'll write up a Wiki page with the current state of the project and > some instructions on how to do things like enable debugging, get > statistics using athstats/wlanstats, TODO/issue lists and such. > > If you'd like to try it out, you'll need to grab it from > svn://svn.freebsd.org/base/user/adrian/if_ath_tx/ . You'll have to add > a few options to your kernel config: > > options ATH_ENABLE_11N > options ATH_DEBUG > options AH_DEBUG > options ATH_DIAGAPI > options IEEE80211_DEBUG > > .. the latter four are so you can actually use the debug tools. > > To preempt some questions - no, I have no plans to get this into > 9.0-RELEASE. And no, I have no current plans to backport this to 9.X > when it's stable and working: > > * I don't (yet) want to try and maintain two branches - 9.x and -HEAD > - during active development (and this is still under active > development); > * There are some intrusive net80211 changes which need to occur which > will break kernel ABIs and I'd to only break the ABI -once- in 9.X. > > That said, I do my current testing on an older -HEAD install (on the > EEEPC) but compile up net80211 + ath + ath_pci as modules. This also > requires you to compile up copies of athstats and wlanstats from the > if_ath_tx branch in order to get debugging information. I'll post some > instructions on how I achieve this as it's quite tricky to get all the > correct environment variables setup so things are built correctly. > > Finally! I'd like to thank Hobnob, Inc. for their generous sponsorship > to date! None of this would have happened without their continuing > support. > I'd also like to thank the ath9k/openwrt developers who have been very > helpful in answering questions about how all of this holds together > (including Felix Fietkau who I've been pestering incessantly with > chipset, 11n and rate control questions - and we've discovered a few > bugs in ath9k along the way.) > > Last and not least! I'd like to thank Atheros/Qualcomm and the > dedicated team of (software, hardware) engineers who have been very > helpful in providing me with chip documentation and reference driver > source code. They've also answered questions about their hardware and > helping me trace down bugs. > > (Yes: I did say "Atheros", "Documentation" and "Reference Driver > Source." No, this isn't 2005 any longer. People still seem to think > FreeBSD's ath(4) support uses a binary HAL. Go figure.) > > > Enjoy! > > > Adrian Just because there usually seems to be silence after you announce yet more updates and advances and as a happy user of some of these advances (albeit under 8.2 so I wont get them all yet.) Thanks for stepping up, taking on and advancing the ath driver as much as you have and are planning to. Its much appreciated. Vince > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org"