search

aparcar / openwrt

Staging tree of Paul Spooren
Other
8 stars 1 forks source link

FS#958 - Archer C2600 - high latency over 5GHz wireless & no intermediate software queues #871

Open aparcar opened 7 years ago

aparcar commented 7 years ago

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: df3295f50e54909090846de12f7deb3ff8de6557

aparcar commented 7 years ago

nopnopnop:

qdisc mq 0: dev wlan0 root qdisc fq_codel 0: dev wlan0 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn qdisc fq_codel 0: dev wlan0 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn qdisc fq_codel 0: dev wlan0 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn qdisc fq_codel 0: dev wlan0 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn qdisc mq 0: dev wlan1 root qdisc fq_codel 0: dev wlan1 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn qdisc fq_codel 0: dev wlan1 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn qdisc fq_codel 0: dev wlan1 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn qdisc fq_codel 0: dev wlan1 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn

This wasn't what I expected on this QCA9980.

aparcar commented 7 years ago

nopnopnop:

This is a problem with the default firmware and with the ct firmware.

aparcar commented 7 years ago

bjonglez:

I don't see a latency issue on 5 GHz on this device, with LEDE 17.01.2. I have the same fq_codel qdisc you've shown, but that's expected, fq_codel is the default on LEDE.

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'

config wifi-iface 'default_radio0' option device 'radio0' option network 'lan' option mode 'ap' option ssid 'SSID' option key 'KEY' option encryption 'psk2'

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

aparcar commented 7 years ago

nopnopnop:

You do have high latency. I have even higher lag spikes for no reason.

aparcar commented 7 years ago

nopnopnop:

An ath9k device has 1ms of latency, not between 2ms and 50ms.

aparcar commented 7 years ago

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.

aparcar commented 7 years ago

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.

aparcar commented 7 years ago

jannispinter:

I have the same problem with my Archer C5 (QCA9880). I can reproduce this issue with LEDE 17.01, LEDE 17.01.3 and latest snapshot release.

Latency is between 20ms and 100ms. Essentially the wifi is unusable with this router.

64 bytes from fd9d:512:d5f2::d5b: icmp_seq=1 ttl=64 time=26.0 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=2 ttl=64 time=48.9 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=3 ttl=64 time=71.7 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=4 ttl=64 time=93.8 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=5 ttl=64 time=14.4 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=6 ttl=64 time=2.07 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=7 ttl=64 time=59.7 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=8 ttl=64 time=81.8 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=9 ttl=64 time=103 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=10 ttl=64 time=24.4 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=11 ttl=64 time=46.7 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=12 ttl=64 time=68.8 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=13 ttl=64 time=90.9 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=14 ttl=64 time=114 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=15 ttl=64 time=33.8 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=16 ttl=64 time=55.7 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=17 ttl=64 time=77.8 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=18 ttl=64 time=99.9 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=19 ttl=64 time=20.4 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=20 ttl=64 time=42.7 ms 64 bytes from fd9d:512:d5f2::d5b: icmp_seq=21 ttl=64 time=64.8 ms

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.