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
FS#958 - Archer C2600 - high latency over 5GHz wireless & no intermediate software queues #5910
Comments
nopnopnop: qdisc mq 0: dev wlan0 root This wasn't what I expected on this QCA9980. |
nopnopnop: This is a problem with the default firmware and with the ct firmware. |
bjonglez: I don't see a latency issue on 5 GHz on this device, with LEDE 17.01.2. Config:
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option htmode 'VHT80'
option country 'FR'
Linux client with Intel 2110 wireless card:
# iw dev wlan0 info
Interface wlan0
ifindex 3
wdev 0x1
addr 30:e3:7a:XX:XX:XX
type managed
wiphy 0
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 22.00 dBm
# ping -n 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.96 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.05 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.57 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.08 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.14 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.907 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.01 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.729 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=1.00 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=0.877 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1.02 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.795 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.18 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=0.906 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1.18 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=0.972 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=1.06 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=0.769 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=1.02 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=2.10 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=1.41 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=1.07 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=2.51 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=14.5 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=1.52 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=2.44 ms
|
nopnopnop: You do have high latency. I have even higher lag spikes for no reason. |
nopnopnop: An ath9k device has 1ms of latency, not between 2ms and 50ms. |
bjonglez: As described above, I am seeing 1ms-2ms of latency, not 2ms-50ms. Also, latency is slightly lower (often below 1 ms) when the wireless link is used. When the link is idle, latency is closer to 2 ms. But anyway, this is still acceptable. |
nopnopnop: The issue and the question are both about immediate queues in ath10k with this wifi chipset. I must test again to post an update with numbers. |
jannispinter:
Latency is between 20ms and 100ms. Essentially the wifi is unusable with this router.
I do not have any latency issues with OpenWrt 15.01.1. Sorry, I forgot that I had [[https://wiki.archlinux.org/index.php/Power_management#Intel_wireless_cards_.28iwlwifi.29|wifi power saving]] enabled on my machine. Disabling it resolved the issue for me. |
nopnopnop:
QCA9980 should have intermediate software queues. Intermediate software queues don't seem to be working. The reqular mq qdisc is in use for the 5GHz wireless.
A previous build had high latency on the 5 GHz wireless interface. The latency was spiking to 20-50ms with a single client.
FS#957 is connected to this bug. The router might be unstable because of the other bug.
LEDE commit: df3295f
The text was updated successfully, but these errors were encountered: