On Wed, May 20, 2020 at 12:20:45PM +0200, stolen data wrote:
> The antennas are just fine - as I mentioned, when rebooting the PC into
> Linux (same hardware, same wireless access point etc.) this WiFi card
> performs perfectly, with no packet loss, low latencies, and maxes out
> transfers at about 22 Mbit/s on 11g and about 70 Mbit/s on 11n.
That doesn't necessarily mean the antennas are fine.
I would assume 70 Mbit/s is possible with the Linux driver even while
just one antenna is working. With MIMO the theoretical max is about
twice that amount.
> The wireless network is on a 2.4 GHz / 20 MHz channel, by the way.
>
> Thanks for the "nomimo" flag hint! It does nothing on 11g but improves
> some for 11n: the 35% packet loss goes down to ~1% and it more or less
> performs identically to 11g, with very jumpy latency and xfer speeds
> swinging up and down between 200 and 1200 KBit/s.
This drop in loss % indicates that MIMO rates do not work. In other words,
it still looks like you might have a broken or disconnected antenna.
That should be 100% ruled out before we look into other possibilities.
If you could open the machine and verify that 2 antennas are indeed
connected properly, that would at least rule out one obvious reason.
And are you sure the Linux driver is using MIMO? In other words, do you
ever see Linux successfully send frames with MCS 8-15 with this device?
Perhaps ath9k somehow detects that MIMO MCS won't work and avoids them?
On Linux you may be able to monitor the current Tx MCS like this:
# iw dev wlan1-1 station dump | grep 'tx bitrate'
tx bitrate: 72.2 MBit/s MCS 7 short GI
This example says the Linux driver is sending frames with MCS 7.
If Linux tends to remain in the MCS 0-7 range, it isn't using MIMO.
The MIMO range is MCS 8-15. So if MIMO is working I would expect Linux
to prefer MCS 8-15 over MCS 0-7.
If MIMO is actually working on Linux but not on OpenBSD, we would then
need to figure out why, though it might not be easy. It would imply that
something is indeed broken with 9287 device support.
> This is still just a fraction of what 11g/n is capable of so something
> is clearly not working correctly with athn(4), at least not for AR9287.
When you compare OpenBSD athn(4) with ath9k you cannot expect to see
the same results. There are several known problems with Tx performance:
- There are still some problems in automatic Tx rate selection in 11n mode.
That's likely where xfer speed fluctuations come from even with nomimo.
Try a fixed rate to side-step the effects of automatic rate selection:
ifconfig athn0 media HT-MCS0 mode 11n
You can try MCS1, MCS2, ..., all the way up to MCS15.
- With our driver the device is often reporting Tx errors at MCS >= 4
for reasons unknown. I can easily trigger this with a fixed Tx rate,
and it gets worse towards higher rates.
The ranges MCS 4-7 and MCS 10-15 cause a lot of output errors which are
visible in 'netstat -I athn0'. This interacts with the above problem
because automatic rate selection tries to avoid non-working rates but
will occasionally attempt to use them to see if they have improved.
Help to find out why this happens would be very welcome. It is quite
possible that our driver doing something wrong or lacks something.
- 11n Tx aggregation is not implemented.
- 11n 40 MHz channel support is not implemented.
Our driver does not have nearly as much refinement as the Linux one,
where you can assume that none of the above restrictions apply.
The Linux driver has received a lot more love by a lot more people,
with active support from Atheros.
The few who are working on the OpenBSD driver can only do so much.
If you need the best and greatest performance on this hardware, my best
answer is that you can help improve the OpenBSD driver or run another
operating system. Another option is switching to different hardware.
The fastest device you can get is a bwfm(4) device, with the caveat that
it runs a black box closed firmware. With athn(4) all code is open and
free and can be fixed. But only when people actually exercise their
freedom and work hard enough on getting it fixed ;)
