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