On Wed, May 20, 2020 at 1:42 PM Stefan Sperling <s...@stsp.name> wrote:
> 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.
>
Yeah it maxes out at ~70 Mbit/s when I'm running on a 20 MHz channel
instead of 40. If I switch to 40 MHz Linux gets close to 150 Mbit/s.
> > 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.
>
I know the antennas are fine because I've already inspected both of
them, along with the male SMC connectors on the card, the solder
joints tying them to PCB, and even doing a continuity test with a
multimeter to test connectivity from the antennas' tips to the vias
on the PCB. I also performed the obvious test of just checking the
connectivity while simply unscrewing one antenna; removing either of
them unsurprisingly disrupts the link entirely, and, conversely,
reattaching it restores the link fully. Like night and day.
> 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.
>
This is what Linux reports when I monitor with iw(8) for a few seconds:
tx bitrate: 130.0 MBit/s MCS 14 short GI
tx bitrate: 130.0 MBit/s MCS 15
tx bitrate: 115.6 MBit/s MCS 13 short GI
tx bitrate: 144.4 MBit/s MCS 15 short GI
> 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.
>
Unfortunately no change. Some are unusable but none of them offer a
visible improvement.
> - 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 ;)
>
Right, I'm familiar with the slightly lower network performance of
OpenBSD when compared to Linux. But averaging 0.7 Mbit/s even on 11g
which on other drivers - such as ral(4) - saturates fully at 22 Mbit/s
really gives me the feeling that something isn't right with athn(4)
when it comes to the AR9287 chip. There's no need for "the best and
greatest performance", and I'm not criticizing anyone's hard work,
I'm just ascertaining that this device driver is not working correctly
as the link quality is not even stable or reasonably performing.
I'll be available for testing of any patches or suggestions that
anyone may have, and thanks for the suggestions so far!
