After further testing I revise assessment of yesterday concerning the influence of band/bandwidth combinations on the crash manifestation. It turns out that the crash can happen on both the 2.4 and 5GHz bands and at both 20 and 40 MHz bandwidths on the 2.4GHz band. It's just less likely to occur at 20MHz bandwidth in the 2.4GHz band than when using 40MHz bandwidth. It also appears that allowing legacy b rates at the AP increases the frequency of the crash. Also configuring the AP to disssociate on low acknowledgement may also increase the crash likelihood.

By disabling legacy b rates and disassociation of low ack at the AP and by performing enough runs, I was able to get transfer throughput measurements in my test harness to compare the 7260 with other cards that I've tested. My throughput test is a simple 1GB file transfer using curl remotehost -> /dev/null. The transfer direction is toward the wireless device, the data is pulled from a wired host.

Card       2.4/20    2.4/40   5.2/80
N5100       5.1MB/s   24.2      5-10*   *Variable, human body modulates BW
N6205      10.1       21.7      22.0    Theoretical max 150/300Mb/s >1/2 OK
AX200      11.2       21.0      49.6    Theoretical 150/300/866Mb/s ~1/2 OK
7260AC     11.0       22.2      23.2    MCS 15 OK, MCS 15 OK, VHT-MCS 7-9 poor AC

In my test harness the 7260 card operates at near what I would call the expected throughput on the 2.4GHz band at both 20MHz and 40MHz channel bandwidths. However, I would characterize the 5.2GHz/80MHz AC throughput as less than stellar, less than half what I would expect. I was hoping for something more akin to the performance of the AX200 client.

The AP that I am currently using is the linksys ea6350v3, which uses the Qualcomm/Atheros ipq4018 SoC. I'm running openWRT on the AP. I like this radio, it is quite consistent, throughtput wise, from one device to another. To clarify, all seven of the ea6350v3's that I have yield similar throughput measurements. For further clarification, I stayed with the geriatric WRT54GL for many years just because I couldn't find a newer device that operated reliably and consistently at a higher level, until the ea6350v3 that is.

root@ea6350f:~# uname -a
Linux ea6350f 4.14.167 #0 SMP Wed Jan 29 16:05:35 2020 armv7l GNU/Linux
root@ea6350f:/etc# cat openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='19.07.1'
DISTRIB_REVISION='r10911-c155900f66'
DISTRIB_TARGET='ipq40xx/generic'
DISTRIB_ARCH='arm_cortex-a7_neon-vfpv4'
DISTRIB_DESCRIPTION='OpenWrt 19.07.1 r10911-c155900f66'
DISTRIB_TAINTS=''

The AP kernel log shows the following messages each time the client 7260 crashes:

[436037.379260] ath10k_ahb a000000.wifi: peer-unmap-event: unknown peer id 0
[436086.794546] ath10k_ahb a800000.wifi: 10.4 wmi init: vdevs: 16  peers: 48  tid: 96
[436086.794591] ath10k_ahb a800000.wifi: msdu-desc: 2500  skid: 32
[436086.841915] ath10k_ahb a800000.wifi: wmi print 'P 48/48 V 16 K 144 PH 176 T 186  msdu-desc: 2500  sw-crypt: 0 ct-sta: 0'
[436086.842966] ath10k_ahb a800000.wifi: wmi print 'free: 56528 iram: 23400 sram: 32520'
[436087.141520] ath10k_ahb a800000.wifi: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4