On Tue, Feb 13, 2018 at 11:00:39PM +0000, Zsolt Kantor wrote:
> So if you have any idea, any new testing method, please tell me, I will try.

The information we'd need to fix anyting is still not there because
what you are measuring is the result of an interaction between many
layers: application, sockets, TCP, IP, wifi, physical medium (radio).

In order to fix anything we'll need to determine which layer is
causing the problem, and why.

I can make a guess, based on my knowledge of how the wifi layer behaves:

The transmit rate used by wpi(4) is selected dynamically by the wifi layer.
The higher the selected transmit rate is the faster your TCP stream will
be because your TCP ACKs will flow faster.

In the current implementation, the wifi layer selects a transmit rate based
on the number of frame transmission retries reported by wpi(4) firmware.

Frame transmission retries at a given transmit rate will happen if either:

1) You are too far away from the AP. A lower rate has more chance
   of getting through so lowering the rate is a good idea.


2) You are close to the AP but there is lots of unrelated wifi traffic
   on the same channel using up air time. Attempts to transmit a frame
   are often blocked by other legitimate frames on the air, so we need
   more than one attempt and all our attempts get counted as retries,
   and now we end up using a lower transmit rate.
   Using a lower rate in this situation means we use up more air time
   and make the problem even worse, not just for us but for everyone
   on this channel.

The access point density in many residential buildings today means that
case 2 is very likely and case 1 is very unlikely, especially on a 2GHz
channel. Adapting the transmit rate based on retries doesn't achieve
the desired result in this situation, so your download speed sucks.

You can test my theory by disabling the automatic rate selection algorithm
and tell wpi(4) to send all frames at a transmit rate of your choice.
To do so, associate to the AP, and now fix the transmit rate as shown below.
Repeat your test each time after changing the transmit rate.

  ifconfig wpi0 media OFDM6 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM9 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM12 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM18 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM24 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM36 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM48 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM54 mode 11g
  # repeat test

If you find that one of these commands makes it work as fast as it does on
Windows, we can conclude that the problem is with OpenBSD's rate selection
algorithm. This algorithm is very old and dates from a time when wifi networks
were much less densly deployed. Windows is probably using a different algorithm
to make decisions about which transmit rate to use (for reference, it probably
uses a similar algorithm as was implemented in Intel's Linux iwlegacy driver,
in file 3945-rs.c of that driver's source code).

Reply via email to