On Mon, Apr 13, 2020 at 07:03:27PM +0200, Mario Theodoridis wrote: > Hi everyone. > > I'm running a APU2 board with an Atheros wlan chipset. > I've been plagued by rather slow WLAN throughput rates < 10Mb/s. > Is that normal or not. If not, how would i go about debugging this? > Any other info i should provide?
Is this a new problem or has it always been like this for you? > Here's an ifconfig > athn0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 There are several known performance issues with athn(4). One is that the device seems unable to send frames at the upper frame data rates. At least in my environment the hardware throws Tx errors when it is asked to send such frames. I don't understand where this is coming from. Automatic rate selection works around it by detecting that some rates don't work and then not using them. But it means we're only using slower rates than the hardware is supposed to be able to transmit frames with. Then are other factors that make things even worse: I am not certain if the block ack Rx logic is correctly working in this driver. It seems the device will only send block ack frames when its block ack window is full (i.e. every 64 frames) or when the client asks for a block ack frame. As far as I understand a block ack should be sent after every aggregate frame which gets received, but this is not the case. This can lead to low throughput for TCP due to redundantly re-transmitted packets or dropped packets. This needs to be debugged and better understood before something can be done. And our automatic rate selection has some performance issues of its own. Also, athn(4) does not support Tx aggregation yet, and 40 MHz channels are not yet suppored either. In practice this means the driver won't be noticably faster in 11n mode than it is in 11a/g modes. For now, I would recommend using 11a mode if you want it to be as fast as possible. I do want to fix all of these issues, but it will take time and help would be very welcome. Another important factor is your RF environment. No amount of bug fixing is going to help when your channel is heavily used by one or more other wifi networks. Ensure that your AP is running on a channel where no other wifi networks can be seen in a scan. > OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020 One way you could help is to keep following -current, upgrade a day or so after any wifi-related commits happen, and letting us know if things are better or worse compared to a previous snapshots.
