[ANNOUNCE] 802.11n TX aggregation support for Atheros 11n NICs

Hi all,

I apologise up front for the cross-posting. Please redirect all future
queries about this to freebsd-wireless_at_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
_______________________________________________
freebsd-net_at_freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe_at_freebsd.org"