hostapd 802.11n Throughput Optimizations

Jouni Malinen j
Wed Jun 10 11:58:28 PDT 2009

On Sun, May 31, 2009 at 02:36:38AM -0700, Galen P Zink wrote:
> I'm trying to optimize 802.11n throughput with hostapd. Before I begin  
> tweaking with the ath9k drivers, I'd like to make sure hostapd is  
> setup for optimal performance.

hostapd does not process any of the normal data frames; all this is done
by the driver (or mac80211 in this case). As such, you will most likely
have to start looking at what is happening in the kernel code.

> Software: Debian unsable with 2.6.29-2 kernel; latest compat-wireless  
> bleeding edge snapshot; <1 day old hostapd snapshot. Dedicated system  
> for wireless testing.
> Hardware: 2 GHz Core Duo CPU, 2 GB RAM, AR5008 miniPCI-e card (3  
> antennas)
> Objective: Maximize 802.11n throughput at 5 GHz, assuming complete  
> control of all stations on the access point. 40 MHz channels desired.

I would suggest testing with a newer kernel version (e.g.,
wireless-testing.git snapshot or alternatively compat-wireless package
on top of your current kernel). There has been number of improvements in
the ath9k driver after 2.6.29.

> Right now, hostapd appears to be yielding lower-than-expected  
> performance, approximately half that of an AR5008 access point. Given  
> the AR5008 card I have is more powerful and has (arguably) better  
> antennas, and a vastly faster CPU, it seems such a large gap may  
> likely be a software issue.

Can you provide some number on what kind of throughput you are seeing
and what your expectations are? I've seen ath9k as an aP provide TCP
throughput well above 100 Mbps in my tests.

> I also am hoping for some clarity on the ht_capab flags as well. I  
> expected [GF] to ban all legacy clients, but it doesn't. What does it  
> do? Is there a way to enforce 802.11n only? Does HT40+ versus HT40-  
> have any impact on client / radio compatibility? Are there any  
> disadvantages to enabling [LDPC] - I'd expect only benefits, unless  
> the CPU were overloaded? I believe ath9k still does not support STBC;  
> is there any harm to having it on, or is STBC somehow handled by  
> hostapd?

[GF] enables Greenfield support which could result in somewhat higher
throughput in some cases at the cost of not working that well with
legacy devices. However, it is not supported by ath9k. I don't think
there is currently any easy option to enforce 802.11n only mode.

HT40+ vs. HT40- should not impact compatibility; it is just defining
whether the primary channel is below or above the secondary one. The
provided value may be ignored if certain rules defined in IEEE 802.11n
match, i.e., no matter what you configure, the primary channel may be
forced to be on the channel that is likely to result in better
coexistence with neighboring devices.

As far as LDPC and STBC are concerned, they are only negotiated by
hostapd; the actual operation is in the driver and that is not yet
available in ath9k.

> ieee80211n=1
> ht_capab=[HT40-][SHORT-GI-40][LDPC][GF][DELAYED-BA][DSSS_CCK-40][MAX- 
> AMSDU-7935][TX-STBC][RX-STBC123]

hostapd (at least the current snapshot) should refuse to run with such a
configuration since they driver you are using does not support those
options.. If you are using a version of hostapd that does not validate
the parameters, you may end up getting interoperability issues if the
clients enables a feature that the driver on the AP does not support.

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list