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