On 11/26/19 10:44 AM, Stijn Tintel wrote: > On 26/11/2019 00:34, Hauke Mehrtens wrote: >> It looks like there is a throughput problem with ath10k-ct on QCA9984, >> https://bugs.openwrt.org/index.php?do=details&task_id=2593 >> there are multiple reports in the Forum. >> >> For me QCA9880 on a BTHH5A with ath10k-ct on 5GHz works in openwrt 19.07 >> The AP can do 180 MBit/s TX and only 40 Mbit/s RX over about 8m with a >> wall in between with sae-mixed to a Intel iwl8265. >> It is also very close to 40MBit/s not much changing the lowest I saw in >> about 30 outputs from iperf3 was 38.8 MBit/s and them highest 41.2 MBit/s > > I am seeing the same low RX with a qca988x AP and an 8265 client. This > did not happen earlier this year. I first noticed this on September 5th, > but I don't have known good commit hash. The problem goes away when I > disable 802.11w. Without 802.11w, I get 300-400Mbps TX and RX. Do you > have any other clients than the 8265 to test this? Ben suggested this > might be an issue on the 8265 end, and to use a sniffer to look into > block-ack setup packets: > > 18|20:29:01< greearb__> sniff the block-ack setup packets, make sure > client sends them encrypted (ie, if you see them open-auth encoded, > sender is issue) > 18|20:30:51< greearb__> you will really want to spend some quality time > with a sniffer to see if block-acks are working or not, and if BA setup > frames are properly encrypted > > Unfortunately the device with the 8265 is my only Linux client with 5GHz > and convenient sniffing support. Some of the Raspberry Pi boards seem to > support it with nexmon, but that looks overcomplicated. Maybe I could > try with my DIR860L, but so far I have not been able to do so. If you > have the equipment for it, maybe you can give it a try? > > Other than that, ath10k-ct is extremely stable on all my APs. Something > that cannot be said about ath10k. With the right combination of clients, > it was crashing within 1 day of uptime, while still sending beacons, > thus clients still trying to associate to the 5GHz network. WiFi > experience with stock ath10k was simply abysmal, almost downright > unusable. It was suggested that this was due to the use of 802.11w, but > disabling 802.11w is not a solution, and in my opinion not even an > option, especially with WPA3.
The BTHH5A uses the VR9 / VRX200, a Lantiq/Intel MIPS 35Kec BE SoC. I connected my IPQ4019 to the QCA9880 and have the same results. IPQ4019 -> QCA9880 ~> 200 MBit/s QCA9880 -> IPQ4019 ~> 36 MBit/s I also sniffed the traffic between my iwl8265 and the QCA9880 with the IPQ4019. I monitored a iperf3 session where I send 46.6 MBytes in 28 seconds from the QCA9880 to the iwl8265 with about 40 MBit/s, I captured 44389 packets with the QCA9880 in monitor mode. 19.5% (8651) of the packets are RTS packets send by the QCA9880, 0.1% (35) of the packets are RTS packets send by other devices. I do not see the data send by the QCA9880 probably because the iwl8265 is closer. I haven't seen any differences when deactivating 802.11w or WPA3. Block Ack are send unencrypted. The IPQ4019 and the QCA9880 used OpenWrt 19.07-rc2 with ath10k-ct. Hauke
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
