AR9287 update

I finally gave in and whacked a FreeBSD-HEAD snapshot on my EEEPC so I can test the ath 802.11n code out with the various mini-PCIe NICs I have.

ath0: mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 on pci1
ath0: [HT] enabling HT modes
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9287 mac 384.2 RF5133 phy 15.15

.. and

wlan0: flags=8843 metric 0 mtu 1500
ether b4:82:fe:33:95:53
inet 10.61.8.27 netmask 0xffffff00 broadcast 10.61.8.255
media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
status: associated
ssid CACHEBOY_RS channel 1 (2412 MHz 11g ht/40+) bssid 00:1b:b1:58:f6:f0
regdomain ROW country AU indoor ecm authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 bmiss 7
scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7
roam:rate 64 protmode CTS -ampdu ampdulimit 32k ampdudensity 8 -amsdu
shortgi wme burst roaming MANUAL

(Yes, there's no TX aggregation support for now so I've disabled ampdu.)

And:

ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG
00:1b:b1:58:f6:f0 1 1 216M 24.5 0 30271 30064 EPS AQEHTRS RSN HTCAP WPA WME

It's happily sitting at MCS12 from my bedroom (which is what I expect given the noise on the 2.4ghz band where I live.)

AR9287 support is now in -HEAD

I've just committed the last bits of the initial AR9287 support to -HEAD.

There's a few bits and pieces that need to be added but there's enough code there now to bring up a station interface and exchange traffic.

The count of Monte Cristo

I spent a couple of weeks reading through the Gutenberg ebook of "The Count of Monte Cristo". All in all I liked it. I could spend some time talking about what I liked, but there's plenty of that already on the internet.

I did however find the level and detail of the intrigues, manipulation, coercion and general dirty play a little on the creepy side. Don't get me wrong, it made a great book, but it felt almost like Dumas had read "The Prince" and decided to write a book putting it into play; a sort of "what if?" scenario where someone had been betrayed and wanted to get back at the world; then finding a suitable vessel to do this through.

AR9160 11n performance - finally!

I've made some good progress with the AR9160 802.11n hostap mode in FreeBSD.

Firstly, the A-MPDU density setting needed tuning. "0" or "N/A" isn't appropriate for the AR9160 (and likely not appropriate for anything earlier than the AR9300/AR9400 series.) Once set to 8 microseconds, the number of A-MPDU retransmits dropped dramatically.

I found that there was some missing code to do with disabling RIFS (reduced inter-frame spacing) RX on the AR9160 which I committed to FreeBSD-HEAD. This has eliminated all of the baseband lockups I've been seeing, rare as they were now.

Then I found there were packets being dropped by if_arge on TX. It turns out the default TX/RX ring buffer size for if_arge was 128 packets - definitely not enough given the uncoupled interrupt/process driven forwarding engine in UNIX these days.

The background: since NIC drivers aren't doing their work in an interrupt or shared process context, they only do their work when their TX/RX tasks get scheduled. Since they don't have any way to signal each other to "back off" via flow control when the queues are getting filled, it's quite possible to have a very busy device (in this instance wlan0 RX'ing anything more than around 100mbit) queue enough packets to the devices' TX queue faster than the TX task can be scheduled to process packets.

Bumping if_arge's default TX/RX ring buffer size from 128 to 1024 did the trick - no more packet drops on TX.

Now I'm getting ~ 105mbit TCP RX in HT/40 5GHz hostap mode (since A-MPDU RX is implemented and working) and ~ 210mbit UDP RX before I begin to drop packets. Anything more than 210mbit starts resulting in the infamous "stuck beacon", but that could be for a variety of reasons. I don't think I'm saturating the PCI bus (read: the CPU scheduler does show about 30% idle clock cycles during a UDP RX test) so there's something else to be blamed.

Next is figuring out whether there's some scheduling issues with the device TX/RX tasks.

I find it quite creepy that I can get ~ 100mbit of 802.11n throughput to my macbook pro whilst lying in bed. But that's what 802.11n is for, right? :)

FreeBSD-HEAD on the PB92 + AR9280

Here's FreeBSD-HEAD up on the Atheros PB92 reference board (AR7242), complete with an AR9280 mini-PCIe NIC.

I'm still only getting around 70mbit in HT/40 mode TCP tests and 90mbit in HT/40 UDP mode; but it's only (currently) connected at 100mbit ethernet. I'll tinker some more with gigabit-connected stuff soon. I hope the UDP throughput maxes out above 100mbit.

It's a far cry from where it should be throughput-wise, but it's getting there.

Another developer has -HEAD + a small patch working on the Ubiquiti Rocket M5 (AR7240 + AR9280 on-board), which is also great progress.


# dmesg | grep ath
ath0: at device 0.0 on pci0
ath0: [HT] enabling HT modes
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9280 mac 128.2 RF5133 phy 13.0
# uname -a
FreeBSD TEST_AP 9.0-CURRENT FreeBSD 9.0-CURRENT #19 r220911:221321M: Mon May 2 22:46:32 WST 2011 adria
n@pcbsd-3114:/data/freebsd/mips/head/obj/mipseb/mips.mipseb/data/freebsd/mips/head/src/sys/PB92 mips
# ifconfig wlan0 list sta
ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG
00:15:6d:84:05:52 1 157 240M 15.5 120 27094 58288 EP AQHTR HTCAP WPA WME
8c:7b:9d:d6:65:ba 2 157 270M 21.5 0 56040 64688 EP AQHTRS RSN HTCAP WME
#