On Sun, Jan 29, 2017 at 07:49:56AM +0200, Timo Myyrä wrote:
> Hmm, I've been running the 11n for a while and it seems to be a lot slower 
> than
> 11g for me. Just did quick benchmark using tcpbench between OpenBSD hostAP 
> (athn) and
> laptop (iwn). It looks when my athn is in 11n mode I get around ~3 Mbps:

Which direction did you measure? Client->AP or AP->Client?
Have you measured both directions? I expect client->AP to be faster if a
non-OpenBSD client is used. Such clients will likely use Tx aggregation.
But OpenBSD does not (yet).

> Quickly looking it seems the 11g is 3x faster than 11n which seems a bit odd.
> I'd assume they should be roughly the same.
> Any idea what could explain the difference?

It might be due to RTS/CTS.

Without TX aggregation, RTS/CTS causes up to 77% overhead on a 20MHz
channel and a 1500 byte MTU. See Figure 10 in
Perhaps this overhead is making the difference?

You could take a look at what is happening at the wifi frame layer and
compare 11n and 11g. To do so, get an iwn(4) device and put it in monitor
mode on the same channel, and use tcpdump's -y IEEE802_11_RADIO option.
This will show control frames such as rts/cts (but only with iwn(4)
because most other drivers unfortunately filter these frames).

You'll see RTS/CTS being exchanged for every frame with an OpenBSD 11n hostap.
This is because OpenBSD 11n hostap forces "HT protection" on. This forces
clients (and the AP) to reserve the medium with an RTS frame before sending
a data frame to avoid collisions from legacy 11a/b/g clients. This is the
simplest way of being standard compliant in any environment.

HT protection could be switched off if only 11n clients exist on the channel
(not just on the same AP), and with good commercial APs you'll see this
behaviour. But OpenBSD's wifi stack does not yet monitor the channel in
a way that allows a decision to be made about turning HT protection off.

In any case, this will likely get better once OpenBSD supports Tx aggregation.
Then it will send multiple frames after reserving the medium with RTS/CTS
and the overhead is reduced.

> There are 8 other wireless networks in range but all of those are on 
> different channels.

Are they on overlapping channels? See here for a good illustration:

If no other networks overlap, or all other networks use 11n only, then
you don't need HT protection. The crude patch below should disable it
and might make 11n and 11g perform equally in your environment.
Obviously this patch is not a real fix and I don't intend to commit it.

Index: ieee80211_node.c
RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
retrieving revision 1.112
diff -u -p -r1.112 ieee80211_node.c
--- ieee80211_node.c    16 Jan 2017 09:35:43 -0000      1.112
+++ ieee80211_node.c    29 Jan 2017 08:37:47 -0000
@@ -364,8 +364,12 @@ ieee80211_create_ibss(struct ieee80211co
                 * beacons from other networks) which proves that only HT
                 * STAs are on the air.
+#if 0
                ni->ni_htop1 = IEEE80211_HTPROT_NONMEMBER;
                ic->ic_protmode = IEEE80211_PROT_RTSCTS;
+               ni->ni_htop1 = IEEE80211_HTPROT_NONE;
                /* Configure QoS EDCA parameters. */
                for (aci = 0; aci < EDCA_NUM_AC; aci++) {
@@ -1476,9 +1480,11 @@ ieee80211_node_join_ht(struct ieee80211c
        /* Update HT protection setting. */
        if ((ni->ni_flags & IEEE80211_NODE_HT) == 0) {
+#if 0
                ic->ic_bss->ni_htop1 = IEEE80211_HTPROT_NONHT_MIXED;
                if (ic->ic_update_htprot)
                        ic->ic_update_htprot(ic, ic->ic_bss);
@@ -1776,9 +1782,11 @@ ieee80211_node_leave(struct ieee80211com
                        panic("bogus non-HT station count %d", ic->ic_nonhtsta);
                if (--ic->ic_nonhtsta == 0) {
                        /* All associated stations now support HT. */
+#if 0
                        ic->ic_bss->ni_htop1 = IEEE80211_HTPROT_NONMEMBER;
                        if (ic->ic_update_htprot)
                                ic->ic_update_htprot(ic, ic->ic_bss);

Reply via email to