athn(4): AR9287 instability

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

athn(4): AR9287 instability

stolen data
>Synopsis: athn(4) AR9287 unstable and poor network quality
>Category: system amd64
>Environment:
System      : OpenBSD 6.7
Details     : OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
[hidden email]:/usr/src/sys/arch/amd64/compile/
GENERIC.MP

Architecture: OpenBSD.amd64
Machine     : amd64
>Description:
I've been testing a supposedly supported Atheros WiFi card to see if it
would work better with 6.7 than it did with 6.6, but unfortunately not.
It's an AR9287 chip on a PCI-express 1x card. I'll provide some details
below, and I'd be happy to test any patches and suggestions.

(PS. the WiFi card works great when I boot the PC into Linux)


while transferring a 440 MiB file on 802.11g
============================================

--- 192.168.1.1 ping statistics ---
641 packets transmitted, 640 packets received, 0.2% packet loss
round-trip min/avg/max/std-dev = 12.367/1577.347/6751.938/1530.703 ms

transfer speed swung between 200 and 1200 Kbit/s, averaging 700 Kbit/s



45 minutes of idle network on 802.11g
=====================================

--- 192.168.1.1 ping statistics ---
2937 packets transmitted, 2924 packets received, 0.4% packet loss
round-trip min/avg/max/std-dev = 11.577/47.667/310.944/34.576 ms



trying to transfer the same 440 MiB file but on 802.11n
=======================================================

the machine's network freezes repeatedly, and ping(8) outputs lots of:

ping: sendmsg: No buffer space available
ping: wrote 192.168.1.1 64 chars, ret=-1

--- 192.168.1.1 ping statistics ---
348 packets transmitted, 227 packets received, 34.8% packet loss
round-trip min/avg/max/std-dev = 29.615/2467.639/6041.608/1004.679 ms



dmesg:
OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
    [hidden email]:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 4268294144 (4070MB)
avail mem = 4126326784 (3935MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf06b0 (57 entries)
bios0: vendor American Megatrends Inc. version "0603" date 08/20/2010
bios0: ASUSTeK Computer INC. P5KPL-AM
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI
acpi0: wakeup devices P0P2(S4) P0P1(S4) PS2K(S4) MC97(S4) P0P4(S4) P0P5(S4)
P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4)
EUSB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 3010.46 MHz, 06-17-06
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,MELTDOWN
cpu0: 6MB 64b/line 16-way L2 cache
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 334MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 3010.04 MHz, 06-17-06
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,MELTDOWN
cpu1: 6MB 64b/line 16-way L2 cache
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 3010.06 MHz, 06-17-06
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,MELTDOWN
cpu2: 6MB 64b/line 16-way L2 cache
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 3010.04 MHz, 06-17-06
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,MELTDOWN
cpu3: 6MB 64b/line 16-way L2 cache
ioapic0 at mainbus0: apid 4 pa 0xfec00000, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf0000000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 2 (P0P4)
acpiprt3 at acpi0: bus 1 (P0P5)
acpiprt4 at acpi0: bus -1 (P0P6)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
acpicpu2 at acpi0: C1(@1 halt!), PSS
acpicpu3 at acpi0: C1(@1 halt!), PSS
acpipci0 at acpi0 PCI0: _OSC failed
acpicmos0 at acpi0
aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM
acpibtn0 at acpi0: PWRB
cpu0: Enhanced SpeedStep 3010 MHz: speeds: 2997, 1998 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x10
inteldrm0 at pci0 dev 2 function 0 "Intel 82G33 Video" rev 0x10
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xe0000000, size 0x10000000
inteldrm0: apic 4 int 16, G33, gen 3
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi
pci1 at ppb0 bus 2
athn0 at pci1 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 4 int 16
athn0: AR9287 rev 2 (2T2R), ROM rev 4, address f8:1a:67:d1:63:d4
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: msi
pci2 at ppb1 bus 1
re0 at pci2 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102EL (0x2480),
msi, address 00:24:8c:6f:c3:f5
rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 4 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 4 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 4 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 4 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 4 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1
pci3 at ppb2 bus 3
pcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 4 int 23 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: <TOSHIBA MK1646GSX>
wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: apic 4
int 23
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL5
spdmem1 at iic0 addr 0x52: 2GB DDR2 SDRAM non-parity PC2-6400CL5
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627DHG-P rev 0x73
lm1 at wbsio0 port 0x290/8: W83627DHG
vmm0 at mainbus0: VMX (using slow L1TF mitigation)
uhidev0 at uhub2 port 1 configuration 1 interface 0 "Cherry USB keyboard"
rev 2.00/1.03 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
uhidev1 at uhub2 port 1 configuration 1 interface 1 "Cherry USB keyboard"
rev 2.00/1.03 addr 2
uhidev1: iclass 3/0, 5 report ids
uhid0 at uhidev1 reportid 2: input=1, output=0, feature=0
uhid1 at uhidev1 reportid 3: input=3, output=0, feature=0
uhid2 at uhidev1 reportid 5: input=0, output=0, feature=5
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (fae101b4a6eb14b7.a) swap on wd0b dump on wd0b
inteldrm0: 1280x1024, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)

usbdevs:
Controller /dev/usb0:
addr 01: 8086:0000 Intel, EHCI root hub
high speed, self powered, config 1, rev 1.00
driver: uhub0
Controller /dev/usb1:
addr 01: 8086:0000 Intel, UHCI root hub
full speed, self powered, config 1, rev 1.00
driver: uhub1
Controller /dev/usb2:
addr 01: 8086:0000 Intel, UHCI root hub
full speed, self powered, config 1, rev 1.00
driver: uhub2
addr 02: 046a:b090 Cherry, USB keyboard
low speed, power 100 mA, config 1, rev 1.03
driver: uhidev0
driver: uhidev1
Controller /dev/usb3:
addr 01: 8086:0000 Intel, UHCI root hub
full speed, self powered, config 1, rev 1.00
driver: uhub3
Controller /dev/usb4:
addr 01: 8086:0000 Intel, UHCI root hub
full speed, self powered, config 1, rev 1.00
driver: uhub4
Reply | Threaded
Open this post in threaded view
|

Re: athn(4): AR9287 instability

Stefan Sperling-5
On Tue, May 19, 2020 at 11:12:01PM +0200, stolen data wrote:

> trying to transfer the same 440 MiB file but on 802.11n
> =======================================================
>
> the machine's network freezes repeatedly, and ping(8) outputs lots of:
>
> ping: sendmsg: No buffer space available
> ping: wrote 192.168.1.1 64 chars, ret=-1
>
> --- 192.168.1.1 ping statistics ---
> 348 packets transmitted, 227 packets received, 34.8% packet loss
> round-trip min/avg/max/std-dev = 29.615/2467.639/6041.608/1004.679 ms

This looks like one of the two antennas isn't connected to the device.

Please check antennas and if that doesn't resolve it, try this workaround:

        ifconfig athn0 nwflag nomimo

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): AR9287 instability

stolen data
On Wed, May 20, 2020 at 10:06 AM Stefan Sperling <[hidden email]> wrote:

> On Tue, May 19, 2020 at 11:12:01PM +0200, stolen data wrote:
> > trying to transfer the same 440 MiB file but on 802.11n
> > =======================================================
> >
> > the machine's network freezes repeatedly, and ping(8) outputs lots of:
> >
> > ping: sendmsg: No buffer space available
> > ping: wrote 192.168.1.1 64 chars, ret=-1
> >
> > --- 192.168.1.1 ping statistics ---
> > 348 packets transmitted, 227 packets received, 34.8% packet loss
> > round-trip min/avg/max/std-dev = 29.615/2467.639/6041.608/1004.679 ms
>
> This looks like one of the two antennas isn't connected to the device.
>
> Please check antennas and if that doesn't resolve it, try this workaround:
>
>         ifconfig athn0 nwflag nomimo
>

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.

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 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.
Reply | Threaded
Open this post in threaded view
|

Re: athn(4): AR9287 instability

Stefan Sperling-5
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 ;)

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): AR9287 instability

stolen data
On Wed, May 20, 2020 at 1:42 PM Stefan Sperling <[hidden email]> 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!
Reply | Threaded
Open this post in threaded view
|

Re: athn(4): AR9287 instability

Stefan Sperling-5
On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote:
> 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.

Awesome. Thanks for confirming.

> 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

Good. So now we have established that this is actually an interesting
bug report :) It would be great to understand what's going on here.
Perhaps figuring out this bug would also help us solve other known issues.

> >   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.

Oh. So they all have the exact same result?

> I'll be available for testing of any patches or suggestions that
> anyone may have, and thanks for the suggestions so far!

What is special about the AR9287 is that it appears in USB devices
as well as PCI.

The USB devices are known to work OK (barring some USB-specific issues).
However, the firmware on USB devices handles large parts of what our driver
is supposed to handle on PCI, so it's another apples to oranges comparison.

The next step would be to grep the Linux and OpenBSD drivers for 9287
and compare chip-specific sections of code that show up. I looked around
for a bit but nothing stands out at first sight.

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): AR9287 instability

stolen data
On Thu, May 21, 2020 at 9:11 AM Stefan Sperling <[hidden email]> wrote:

> On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote:
>
> ...
>

> > >   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.
>
> Oh. So they all have the exact same result?
>

None of MCS0-15 can reach beyond 1200 Kbit/s and some are exceptionally
unstable; 5-7 and 13-15 (with emphasis on 7 and 15) are so shaky that
the speed drops below 50 Kbit/s and sometimes cause the entire link to
choke and drop out. Across the range it seems to be best at 0/8 and
degrade towards 7/15. I can't see any difference between the lower and
upper range, and autoselect overall seems to work out better over time
despite still being very jumpy.


>
> > I'll be available for testing of any patches or suggestions that
> > anyone may have, and thanks for the suggestions so far!
>
> What is special about the AR9287 is that it appears in USB devices
> as well as PCI.
>
> The USB devices are known to work OK (barring some USB-specific issues).
> However, the firmware on USB devices handles large parts of what our driver
> is supposed to handle on PCI, so it's another apples to oranges comparison.
>
> The next step would be to grep the Linux and OpenBSD drivers for 9287
> and compare chip-specific sections of code that show up. I looked around
> for a bit but nothing stands out at first sight.
>
Reply | Threaded
Open this post in threaded view
|

Re: athn(4): AR9287 instability

Stefan Sperling-5
On Fri, May 22, 2020 at 05:12:23PM +0200, stolen data wrote:

> On Thu, May 21, 2020 at 9:11 AM Stefan Sperling <[hidden email]> wrote:
>
> > On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote:
> >
> > ...
> >
>
> > > >   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.
> >
> > Oh. So they all have the exact same result?
> >
>
> None of MCS0-15 can reach beyond 1200 Kbit/s and some are exceptionally
> unstable; 5-7 and 13-15 (with emphasis on 7 and 15) are so shaky that
> the speed drops below 50 Kbit/s and sometimes cause the entire link to
> choke and drop out. Across the range it seems to be best at 0/8 and
> degrade towards 7/15. I can't see any difference between the lower and
> upper range, and autoselect overall seems to work out better over time
> despite still being very jumpy.
>

On AR9280 OpenBSD athn(4) will easily do 10 Mbit/s under good conditions,
if not more. Which is fairly bad given what the hardware is capable of.
But not nearly as bad as what you're seeing.

It really sounds like a case where someone with AR9287 hardware in front
of them will need to debug the driver.

Recording packet captures with another device in monitor mode might be
worth doing just to see if it sheds some light on the problem.

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): AR9287 instability

stolen data
On Sat, May 23, 2020 at 9:57 AM Stefan Sperling <[hidden email]> wrote:

> On Fri, May 22, 2020 at 05:12:23PM +0200, stolen data wrote:
> > On Thu, May 21, 2020 at 9:11 AM Stefan Sperling <[hidden email]> wrote:
> >
> > > On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote:
> > >
> > > ...
> > >
> >
> > > > >   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.
> > >
> > > Oh. So they all have the exact same result?
> > >
> >
> > None of MCS0-15 can reach beyond 1200 Kbit/s and some are exceptionally
> > unstable; 5-7 and 13-15 (with emphasis on 7 and 15) are so shaky that
> > the speed drops below 50 Kbit/s and sometimes cause the entire link to
> > choke and drop out. Across the range it seems to be best at 0/8 and
> > degrade towards 7/15. I can't see any difference between the lower and
> > upper range, and autoselect overall seems to work out better over time
> > despite still being very jumpy.
> >
>
> On AR9280 OpenBSD athn(4) will easily do 10 Mbit/s under good conditions,
> if not more. Which is fairly bad given what the hardware is capable of.
> But not nearly as bad as what you're seeing.
>
> It really sounds like a case where someone with AR9287 hardware in front
> of them will need to debug the driver.
>
> Recording packet captures with another device in monitor mode might be
> worth doing just to see if it sheds some light on the problem.
>

Would you be able to instruct me in how to capture traffic for this
particular scenario? Assuming a packet dump from my end would be of
any help that is.

If none of the developers have an AR9287 available I will gladly lend
this card for that purpose, granted that whoever receives it is OK
with returning it afterwards. I'll pay shipping both ways of course.
Reply | Threaded
Open this post in threaded view
|

Re: athn(4): AR9287 instability

Stefan Sperling-5
On Mon, May 25, 2020 at 11:46:22PM +0200, stolen data wrote:

> On Sat, May 23, 2020 at 9:57 AM Stefan Sperling <[hidden email]> wrote:
>
> > On Fri, May 22, 2020 at 05:12:23PM +0200, stolen data wrote:
> > > On Thu, May 21, 2020 at 9:11 AM Stefan Sperling <[hidden email]> wrote:
> > >
> > > > On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote:
> > > >
> > > > ...
> > > >
> > >
> > > > > >   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.
> > > >
> > > > Oh. So they all have the exact same result?
> > > >
> > >
> > > None of MCS0-15 can reach beyond 1200 Kbit/s and some are exceptionally
> > > unstable; 5-7 and 13-15 (with emphasis on 7 and 15) are so shaky that
> > > the speed drops below 50 Kbit/s and sometimes cause the entire link to
> > > choke and drop out. Across the range it seems to be best at 0/8 and
> > > degrade towards 7/15. I can't see any difference between the lower and
> > > upper range, and autoselect overall seems to work out better over time
> > > despite still being very jumpy.
> > >
> >
> > On AR9280 OpenBSD athn(4) will easily do 10 Mbit/s under good conditions,
> > if not more. Which is fairly bad given what the hardware is capable of.
> > But not nearly as bad as what you're seeing.
> >
> > It really sounds like a case where someone with AR9287 hardware in front
> > of them will need to debug the driver.
> >
> > Recording packet captures with another device in monitor mode might be
> > worth doing just to see if it sheds some light on the problem.
> >
>
> Would you be able to instruct me in how to capture traffic for this
> particular scenario? Assuming a packet dump from my end would be of
> any help that is.

On another OpenBSD machine that is in range of the AR9287 device and the AP,
put, ideally an iwn(4) or iwm(4) wireless device into monitor mode, and use
tcpdump to record a pcap file:

  ifconfig iwn0 mediaopt monitor chan 1

  tcpdump -n -i iwn0 -y IEEE802_11_RADIO -s 4096 -w /tmp/iwn.pcap
 
Adjust the channel number as needed.

The pcap file can be read with tcpdump -r or with wireshark from ports.

Whether or not this will be of any help is hard to tell ahead of time.
In the worst case we learn nothing new.