Date: Wed, 07 Sep 2011 10:44:44 +0100 From: Vincent Hoffman <vince@unsane.co.uk> To: freebsd-wireless@freebsd.org Subject: Re: [ANNOUNCE] 802.11n TX aggregation support for Atheros 11n NICs Message-ID: <4E673D0C.7040504@unsane.co.uk> In-Reply-To: <CAJ-Vmo=ztbA6qYt7=sGY=j0%2B9yTiedhdnz0D47K8HTkecdc4AA@mail.gmail.com> References: <CAJ-Vmo=ztbA6qYt7=sGY=j0%2B9yTiedhdnz0D47K8HTkecdc4AA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E673D0C.7040504>