Stefan Sperling <s...@stsp.name> 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. > https://en.wikipedia.org/wiki/IEEE_802.11_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 > http://www.nle.com/literature/Airmagnet_impact_of_legacy_devices_on_80211n.pdf > 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: > https://en.wikipedia.org/wiki/IEEE_802.11#/media/File:2.4_GHz_Wi-Fi_channels_(802.11b,g_WLAN).svg > 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 > } > } > Timo
