-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bad tcp performance compared to stock firmware when .11w is enabled (block-ack fails) #31
Comments
Apparently it seems to be related to 11W. After disabling 11W, the performance with -ct-htt seems to be very close to stock:
|
As requested, hostapd-phy0.conf:
|
ath10k-ct with stock firmware
|
I also experience this issue with ath10k-ct and the -htt firmware. /ect/config/wireless:
/var/run/hostapd-phy0.conf:
Software AP: NETGEAR R7800 running OpenWrt master ipq806x: r7855-d20f4fc628 Hardware [ 13.617220] ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe Logs ath10k-ct + ct-htt firmware
Here are the results when I disable 802.11w:
|
The root cause was block-ack failing in 11w mode. I fixed this by backporting the appropriate code from 10.2 firmware and updating the driver to allow 11w mode in 10.1 firmware. Appears to be fixed now. |
EDIT summary by Ben: Performance is fine when .11w is disabled, and is fine with -ct driver and stock firmware with both .11w and without. Problem seems to be just with -ct firmware and .11w being enabled. The problem is that ct firmware fails to do block-ack with 11w, at least in hw-crypt mode.
I tried to reproduce on different hardware and the 4.16.18+ ct kernel and could not detect any problems with tcp or udp with 11w and -ct firmware.
Description of the problem (how to configure, how to reproduce, how often it happens).
Being fed up with the instability of ath10k, I decided to try your driver / firmware. Unfortunately I'm experiencing quite terrible performance with it. I initially tried this a few months ago. My WiFi connection was so slow at that time, that I couldn't even stream a 720p video. As I wanted to continue watching, I reverted back to stock without further testing. After our conversation in #openwrt-devel a few weeks ago, I am now retesting everything.
I thought that with all combinations of ath10k stock with your firmware, ath10k-ct with -ct firmware and ath10k-ct with -ct-htt firmware were equally bad. Testing now shows that this is not true. It's with ath10k-ct and -ct-htt firmware that performance is so bad that it makes it unusable. See the iperf results below. The tests were done with both the AP and the client in the exact same location (in the bedroom with closed doors, doors have windows in them). The distance between the AP and client is roughly 9m.
/etc/config/wireless:
Software (OS, Firmware version, kernel, driver, etc)
AP: Ubiquiti Unifi AP AC Pro running OpenWrt master (ath79) built from blogic's staging tree (mac80211 4.18-rc7)
Client: Dell XPS13 9343 w/ Intel 8265 running Gentoo Linux w/ 4.17.13 kernel
Hardware (NIC chipset, platform, etc)
Ubiquiti Unifi AP AC Pro
[ 22.543045] ath10k_pci 0000:00:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
Logs (dmesg, maybe supplicant and/or hostap)
ath10k + stock firmware
ath10k + ct firmware
ath10k-ct + ct firmware
ath10k-ct + ct-htt firmware
The text was updated successfully, but these errors were encountered: