Stefan Sperling <s...@stsp.name> writes: > On Mon, Mar 06, 2017 at 07:36:21AM +0200, Timo Myyrä wrote: > >> Did some tcpbench testing and got following results: >> Each test run with: tcpbench -s || tcpbench -t 15 <host> commands. >> Host AP: apu 2b4 with athn, client = thinkpad t430s with iwn (OpenBSD) >> >> channel 9 running old snapshot etc: >> 11n client -> server ~4, server -> ~0, >> 11g client -> server ~16, server -> client ~0-6mbs >> --- >> updated to new snapshot: OpenBSD 6.0-current (GENERIC.MP) #206: Sat Mar 4 >> 09:22:00 MST 2017 >> = added another antenna, moved the ap to better spot, switched old ap off, >> changed channel to 11 >> 11n client -> server: ~6mbps, server -> client ~0.2mbps >> 11g client -> server: ~7mbps, server -> client ~3mbps >> >> --- >> switch to channel 3: >> 11n client -> server: ~7mbps, server -> client: ~0-5mbps >> 11g client -> server: 16mbps, server -> client: ~5mbps >> >> --- >> applied dyn rts patch: >> 11n client -> server: 4-7mbps, server -> client 0.2-5.5mbps >> 11g client -> server: ~4mbps, server -> client: ~5.5mbps > > What made 11n go down from 16 to 4? > 11g is not affected by this patch so something else affected 11g. > Could it be other networks on overlapping channels?
Yeah, I have around ten wireless networks around. Some seem to be mobile AP which come and go. > > To tell whether the patch has any effect in your case I would like to > know which HT protection setting your AP is using. > > Find a snapshot dated a bit after 2017/03/04 10:51:20 MST, or make sure > tcpdump > sources are -current and rebuild and install tcpdump. Associate to the AP, > and run: tcpdump -n -i iwn0 -y IEEE802_11_RADIO -s 4096 -v -l | grep beacon > and in htop=<...> look for 'htprot'. If it shows 'htprot none' then dynamic > RTS is used in 11n mode (i.e. my patch will switch RTS on/off as needed). > Otherwise, you have some pre-11n devices in your environment so RTS must > always be enabled and my patch makes no difference. 06:59:51.809091 802.11 flags=0<>: beacon, caps=2061<ESS,PRIVACY,SHORT_PREAMBLE,SHORT_SLOTTIME>, ssid (wifee), rates 1M* 2M* 5M* 11M* 6M 9M 12M 18M, ds (chan 6), tim 0x00010000, xrates 24M 36M 48M 54M, rsn 0x0100000fac040100000fac040100000fac0200000000, htcaps=<20MHz,A-MSDU 3839,A-MPDU max 8191,RxMCS 0xffff0000000000000000>, htop=<20MHz chan 6,STA chanw 20MHz,htprot non-HT-mixed,basic MCS set 0x0000000000000000>, vendor 0x0050f2020101000003a4000027a4000042435e0062322f00, <radiotap v0, 1Mbit/s, chan 6, 11n, sig -29dBm, noise -91dBm> So I guess its pre-11n devices somewhere ruining my day. > > Note that the iwn(4) driver does not yet support MIMO in 11n mode. > Once it does, 11n should become faster than 11g. I have seen an iwm(4) client > which supports MIMO max out at 21 Mbps tcpbench towards my athn(4) AP, on a > 5GHz channel with 'htprot none'. > Unfortunately, tcpbench in the other direction (athn -> iwm) peaks at 10 Mbps. > There is plenty of room for improvement. > I didn't think it would improve things yet but I had the antenna so I'd figure I'd stick it in the AP while I'm tweaking it anyway. Speaking of 5Ghz, my AP uses athn chipset AR9280 which seems to support 2.4Ghz and 5Ghz. Can I use 5Ghz with my AP to see which devices would break after such transition. I guess I would need to get 5Ghz antenna and just stick that to my AP? Can OpenBSD AP work on both frequencies at the same time or is that something not yet supported? >> At least what pops up in the measurements is that 11g gives more stable >> behaviour. 11n speed seems to vary a lot in that 15s test compared to 11g. > > This could be explained by differences in rate scaling algorithms. > In -current 11g uses AMRR, and 11n mode uses MiRa which jumps around more. > In 6.0 everything used AMRR so a comparing how a 6.0 iwn client performs > in 11n mode would be useful (you could e.g. install 6.0 to a USB stick > and boot from it for running a speed test). I have only very limited observations, like typing commands via ssh has usually lag with 11n and works pretty smoothly on 11g. timo
