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
#

AR913x support in -HEAD, or TP-Link WR-1043nd

In summary:

KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #6 r220911:221160M: Thu Apr 28 20:09:28 WST 2011
adrian@pcbsd-3114:/data/freebsd/mips/head/obj/mipseb/mips.mipseb/data/freebsd/mips/head/src/sys/TP-WN1043ND mips
real memory = 33554432 (32768K bytes)
avail memory = 21123072 (20MB)
nexus0:
clock0: on nexus0
Timecounter "MIPS32" frequency 200000000 Hz quality 800
Event timer "MIPS32" frequency 200000000 Hz quality 800
apb0 at irq 4 on nexus0
uart0: <16550 or compatible> on apb0
uart0: console (115200,n,8,1)
ehci0: at mem 0x1b000100-0x1bffffff irq 1 on nexus0
usbus0: set host controller mode
usbus0: EHCI version 1.0
usbus0: set host controller mode
usbus0: on ehci0
arge0: at mem 0x19000000-0x19000fff irq 2 on nexus0
arge0: Overriding MAC from EEPROM
arge0: Ethernet address: 94:0c:6d:fe:4f:20
arge1: at mem 0x1a000000-0x1a000fff irq 3 on nexus0
device_attach: arge1 attach returned 22
ath0: at mem 0x180c0000-0x180effff irq 0 on nexus0
ath0: eeprom @ 0x1fff1000
ath0: eeprom data @ 0xbfff1000
ath0: [HT] enabling HT modes
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9130 mac 20.1 RF2133 phy 10.2
spi0: at mem 0x1f000000-0x1f00000f on nexus0
spibus0: on spi0
mx25l0: at cs 0 on spibus0
mx25l0: s25sl064a, sector 65536 bytes, 128 sectors
ar71xx_wdog0: on nexus0
ar71xx_wdog0: Previous reset was due to watchdog timeout
Timecounters tick every 1.000 msec
usbus0: 480Mbps High Speed USB v2.0
md0.uzip: 855 x 16384 blocks
ugen0.1: at usbus0
uhub0: on usbus0
Root mount waiting for: usbus0
uhub0: 1 port with 1 removable, self powered
Root mount waiting for: usbus0
ugen0.2: at usbus0
umass0: on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x0000
Root mount waiting for: usbus0
umass0:0:0:-1: Attached to scbus0
Trying to mount root from ufs:/dev/md0 []...
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 3835MB (7856127 512 byte sectors: 255H 63S/T 489C)
Mounting from ufs:/dev/md0 failed with error 22.
Trying to mount root from ufs:/dev/md0.uzip []...
warning: no time-of-day clock registered, system time will not be set accurately
bridge0: Ethernet address: 06:26:1a:6f:d5:e7
wlan0: Ethernet address: 00:19:e0:66:66:68

And the wireless:

# ifconfig wlan0
wlan0: flags=8943 metric 0 mtu 1500
ether 00:19:e0:66:66:68
inet6 fe80::219:e0ff:fe66:6668%wlan0 prefixlen 64 scopeid 0x6
nd6 options=21
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng
status: running
ssid CACHEBOY_RS channel 6 (2437 MHz 11g ht/40+) bssid 00:19:e0:66:66:68
regdomain ROW country AU ecm authmode WPA1+WPA2/802.11i privacy MIXED
deftxkey 2 TKIP 2:128-bit txpower 30 scanvalid 60 protmode CTS
-ampdutx ampdurx ampdulimit 64k -amsdu shortgi wme burst dtimperiod 1
-dfs

I'll see about sneaking this into -HEAD soon.

Oh god, so much wireless hardware..

Since I've started doing wireless development, people seem to be sending me more and more hardware. (I've also bought some stuff off of ebay too, so I'm partially to blame for this. :-)

So there's this group of developers over in Europe/Russia who have been busy porting FreeBSD to a variety of wireless devices, but their work hasn't made it into the main FreeBSD tree (or been published at all in any public way.) I've been liaising with Aleksandr Rybalko to push their work into -HEAD in time for FreeBSD-9.0.

So far this has included:

• Support for the Ralink RT305x MIPS SoC, with initial peripheral support;
• nvram2env, a way of importing the environment from various bootloaders (eg uboot) into the kernel environment;
  
• geom_map, a GEOM module which describes the flash layout for fixed flash partitioning schemes (again like uboot, but it can be used for anything.)

There's a few other things coming up soon, such as support for one of the Broadcom MIPS SoCs, further peripheral support for the RT305x (including the embedded wireless MAC/radio) and other bits and pieces which will prove to be useful.

It's been a pleasure working with them