Stefan Sperling <> writes:

> 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).

Initially I just measured Client->AP. I did another measurement yesterday
looking at traffic in both ways and got pretty poor results. The AP->Client when
in 11n mode had throughput between 0-2 Mbps. I did test it during evening so
there might have been a bit more interference but still, that wasn't very
promising result.

But good news is that I noticed your commits to athn and did a new benchmarks
with those changes:
11g: Client->AP: ~15Mbps, AP->Client: ~5Mbps
11n: Client->AP: ~3Mbps, AP->Client: ~5Mbps

So it seems to improved the AP->Client traffic somewhat or its just that I get
full bandwidth to myself in the mornings. 

>> 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?

Perhaps, I need to take a moment to digest the document.

> 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.

Ok, good to know. if I find a good moment I'll try to mess around with tcpdump a
bit to see if anything pops up.

>> 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:

Seems they are overlapping a bit. Will try to find clearer channel for my wifi.

> 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;
> +#else
> +             ni->ni_htop1 = IEEE80211_HTPROT_NONE;
> +#endif
>               /* 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) {
>               ic->ic_nonhtsta++;
> +#if 0
>               ic->ic_bss->ni_htop1 = IEEE80211_HTPROT_NONHT_MIXED;
>               if (ic->ic_update_htprot)
>                       ic->ic_update_htprot(ic, ic->ic_bss);
> +#endif
>       }
>  }
> @@ -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);
> +#endif
>               }
>       }


Reply via email to