[OpenWrt-Devel] OpenWrt 19.07 status

[Hauke Mehrtens]

On 12/6/19 12:23 AM, Hauke Mehrtens wrote:
> 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.

I did some more tests and see the same behavior with OpenWrt 18.06 and
also with ath10k without ct and a similar behavior with Lede 17.01
(~50MBit/s). I used iperf running on the device, when I run it on an
external device and do forwarding, it is faster, but still not good.
The DMA handling in the lantiq Ethernet driver is not good and should
probably be improved, there were some patches on the mailing list some
time ago, but they needed some more cleanups.

From my side I do not see this as a regression and will not block the
19.07 release with this.

Hauke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20191210/7d4aeadc/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel