High ping on WRT1900ACS

[lefoyer]

Two days ago, I bought this device, and flashed firmware (first test OpenWRT 15.05.1, next probe http://personalpages.tds.net/~davidc502/mvebu/Kernel4.4.6/4.4WNandPatchShelby/openwrt-mvebu-armada-385-linksys-shelby-squashfs-factory.img). I Tried 2Ghz & 5Ghz everywhere high ping (12-30ms+), to router and all connected to router devices and internet. Distance from the laptop to the router 3 meters, no walls. From time to time the device reboots itself. Speed on 5Gnz falls from 320Mbit/s to 64Mbit/s on copy file from NAS (but Wifi speed 866.5Mbit/s). -55 dbm -89 dbm 234.0 Mbit/s, MCS 0, 20Mhz 866.7 Mbit/s, MCS 0, 20MHz I am find identical problem https://dev.openwrt.org/ticket/22130 Previous router flashed by OpenWRT RB2011UAS-2HnD-IN there were no problems? ping smolest 1 ms.

[Razerwire]

Thank god, i thought i was the only one experiencing this.....

I'm experiencing the same issue (high latency when connected via WiFi) with clients running Linux Kernel 4.5 and newer and Windows-10, in combination with Intel Wireless-AC 7265 and and Intel AC 8260.

I'm not seeing high latency when using my Netgear R7000 so it isn't my internet connection that is at fault.

[lefoyer]

My client: Win 7 Pro, Broadcom BCM94352HMB (AW-CE123H).

[itrankolov]

Hi, I have the same problem. It was introduced with driver version > 10.3.0.12. The issue is related to WMM. If I disable WMM the latency goes down to < 1ms, but the link speed goes to 54M only as well, so this is not a solution. This is happening with 3 different laptops (with different wifi adapters).

[MrDoh]

Been seeing long ping times with the WRT1900ACv1 on one of my Apple clients on every version of the wireless driver that I've used, maybe even before 10.3.0.12, including on 10.3.0.17. The internet ping time on my Apple iPad Air 2 is more than double the time that I see on other routers (37ms. versus <=15ms. on other routers). And now I'm also getting the same ballpark long ping time on my Nexus 6P phone. This is very frustrating, especially since I don't see this on the stock Linksys firmware. I'm glad to see it finally being reported and discussed. Love to see this finally get fixed.

[itrankolov]

The issue in my opinion is related to AMPDU priorities. For some reason the driver is treating everything as low priority traffic (best effort).

[suihkulokki]

If you have linux, you can try different ToS values with ping using the -Q parameter. ping -Q 0x2E if using different values decrease latency for you, then it's indeed a priority related issue. For values to try, see: https://www.bintec-elmeg.com/portal/downloadcenter/dateien/workshops/current_en/ws_wlan_html_en_HTML/vowlan_infra_qos_wmm.html

[itrankolov]

Hi, I've already tried that and that pointed to issues with AMPDU:

root@debian:~# ping 192.168.1.100 -c 10 PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. 64 bytes from 192.168.1.100: icmp_seq=1 ttl=128 time=17.6 ms 64 bytes from 192.168.1.100: icmp_seq=2 ttl=128 time=15.0 ms 64 bytes from 192.168.1.100: icmp_seq=3 ttl=128 time=32.6 ms 64 bytes from 192.168.1.100: icmp_seq=4 ttl=128 time=30.2 ms 64 bytes from 192.168.1.100: icmp_seq=5 ttl=128 time=28.6 ms 64 bytes from 192.168.1.100: icmp_seq=6 ttl=128 time=27.7 ms 64 bytes from 192.168.1.100: icmp_seq=7 ttl=128 time=25.2 ms 64 bytes from 192.168.1.100: icmp_seq=8 ttl=128 time=22.6 ms 64 bytes from 192.168.1.100: icmp_seq=9 ttl=128 time=21.4 ms 64 bytes from 192.168.1.100: icmp_seq=10 ttl=128 time=20.1 ms

--- 192.168.1.100 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9017ms rtt min/avg/max/mdev = 15.005/24.139/32.629/5.435 ms root@debian:~# ping 192.168.1.100 -c 10 -Q 48 PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. 64 bytes from 192.168.1.100: icmp_seq=1 ttl=128 time=2.49 ms 64 bytes from 192.168.1.100: icmp_seq=2 ttl=128 time=3.05 ms 64 bytes from 192.168.1.100: icmp_seq=3 ttl=128 time=3.60 ms 64 bytes from 192.168.1.100: icmp_seq=4 ttl=128 time=3.08 ms 64 bytes from 192.168.1.100: icmp_seq=5 ttl=128 time=3.21 ms 64 bytes from 192.168.1.100: icmp_seq=6 ttl=128 time=2.99 ms 64 bytes from 192.168.1.100: icmp_seq=7 ttl=128 time=3.07 ms 64 bytes from 192.168.1.100: icmp_seq=8 ttl=128 time=3.03 ms 64 bytes from 192.168.1.100: icmp_seq=9 ttl=128 time=2.90 ms 64 bytes from 192.168.1.100: icmp_seq=10 ttl=128 time=3.17 ms

--- 192.168.1.100 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9017ms rtt min/avg/max/mdev = 2.492/3.061/3.600/0.271 ms

[yuhhaurlin]

This issue will be enhanced for next release.

[yuhhaurlin]

It is related to AMSDU.

[itrankolov]

Another sample to router from physical machine: root@openwrt-builder:~# ping 192.168.1.1 -Q 48 -c 10 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.92 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=2.90 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.12 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=2.63 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=2.09 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=2.46 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=2.52 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.81 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=2.45 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=2.78 ms

--- 192.168.1.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9126ms rtt min/avg/max/mdev = 1.814/2.372/2.909/0.353 ms root@openwrt-builder:~# ping 192.168.1.1 -c 10 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=25.9 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=17.7 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=22.6 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=26.8 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=30.7 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=15.6 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=19.8 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=23.7 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=28.3 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=26.2 ms

--- 192.168.1.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9119ms rtt min/avg/max/mdev = 15.651/23.795/30.774/4.573 ms

[itrankolov]

@yuhhaurlin Thanks for the update. Hopefully it will resolve the issues, because that forced me to buy another device, that I am not happy with ....

[yuhhaurlin]

However, this issue will not affect throughput.

[itrankolov]

Yes it does not affect throughput, but it affects latency and that is a problem when you're making voice calls, playing games and doing other stuff that is heavy reliant on latency.

[yuhhaurlin]

The problem is that if traffic is not heavy and AMSDU is on. AMSDU packets must wait for flush function to send them out.

[yuhhaurlin]

Basically, this issue will only affect single ping. However, I will enhance it on next release.

[itrankolov]

The interesting thing is that it is not obeying the setting on the parameter in the wireless adapter advanced settings - U-APSD Support. It does not matter if I set it to disabled. I don't know if there is an option to disable AMPDU support on the adapter in OpenWRT? This may be useful as a workaround.

[itrankolov]

@yuhhaurlin it is not affecting only ping .... RDP, Voice, PCoIP and others are affected as well. For example if I disable WMM I get PCoIP latency of <2ms. With it enabled it is above 20ms. The only thing it is not affecting is huge file transfers/downloads.

[yuhhaurlin]

Flush function is called around 10ms, the minimum sample interval of CODEC is 10ms. I think the driver should be all right for VoIP application.

[yuhhaurlin]

BTW, only AMSDU will affect ping latency. AMPDU will not.

[itrankolov]

I am not sure ... I mean, I am just guessing about the protocol responsible for the latency. My observations on the other side are correct. When is the new driver expected to arrive?

[yuhhaurlin]

I think running with 10.3.0.17-20160520, this problem should be gone.

[johnnysl]

I never have really experienced the issue, But gave the newest commit some quick testing:

Very first ping to router via 5ghz: Pinging 192.168.1.1 with 32 bytes of data: Reply from 192.168.1.1: bytes=32 time=21ms TTL=64 Reply from 192.168.1.1: bytes=32 time=27ms TTL=64 Reply from 192.168.1.1: bytes=32 time=32ms TTL=64 Reply from 192.168.1.1: bytes=32 time=38ms TTL=64

Ping statistics for 192.168.1.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 21ms, Maximum = 38ms, Average = 29ms

so that is not good. tried google after that:

Pinging www.google.com [74.125.136.105] with 32 bytes of data: Reply from 74.125.136.105: bytes=32 time=10ms TTL=49 Reply from 74.125.136.105: bytes=32 time=10ms TTL=49 Reply from 74.125.136.105: bytes=32 time=10ms TTL=49 Reply from 74.125.136.105: bytes=32 time=10ms TTL=49

thats really nice.

retried the router: Pinging 192.168.1.1 with 32 bytes of data: Reply from 192.168.1.1: bytes=32 time=1ms TTL=64 Reply from 192.168.1.1: bytes=32 time=1ms TTL=64 Reply from 192.168.1.1: bytes=32 time=1ms TTL=64 Reply from 192.168.1.1: bytes=32 time=1ms TTL=64

that looks a lot better. Pinging the router stayed fast after that.

only thing i observe is that the initial ping is slow after a longer pause (5min) between the ping tries; e.g. Pinging www.google.com [74.125.136.105] with 32 bytes of data: Reply from 74.125.136.105: bytes=32 time=151ms TTL=49 Reply from 74.125.136.105: bytes=32 time=10ms TTL=49 Reply from 74.125.136.105: bytes=32 time=10ms TTL=49 Reply from 74.125.136.105: bytes=32 time=10ms TTL=49

Roughly the same with pinging the router, there i see initial pings going up to 10/11 msec. (if pause using the wifi for a minute or 5)

[edit] copied the wrong info here and there, corrected it now

[yuhhaurlin]

Thanks. I will close this one.

[MrDoh]

How can you close this issue when the person that emaled said that "I never have really experienced the issue," I think that you should get some testing from someone who has experienced the issue before closing it, don't you? Closing this issue without real testing and verification doesn't make any sense to me.

Thanks.

-Roger

On Fri, May 20, 2016 at 5:16 PM, yuhhaurlin notifications@github.com wrote:

Thanks. I will close this one.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/kaloz/mwlwifi/issues/74#issuecomment-220746309

[yuhhaurlin]

Thanks. Reopen it.

[MrDoh]

Thank you very much!

-Roger

On Fri, May 20, 2016 at 6:22 PM, yuhhaurlin notifications@github.com wrote:

Thanks. Reopen it.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/kaloz/mwlwifi/issues/74#issuecomment-220750861

[bill1228]

I agree with MrDoh. I do have high ping times from one device to the router via 5GHz wireless others work fine. The one that doesn't is a TP-Link T4U USB wireless adapter with latest driver from TP-Link. This adapter is a Ralink chip for what it is worth.. This should not be closed until it is proven by more then one person/test that there is not a problem. If I tested with any of the other devices I have you would say it was fixed, but really fixed in my opinion. There are too many folks complaining about high ping times with the latest driver to not think there is still an issue.

Thanks for reopening it. Am looking forward to the new driver. --bill

[yuhhaurlin]

Does anyone still get high ping Times for the latest driver?

[MrDoh]

I haven't seen a build yet with the latest driver. I'd be glad to test one, though.

By the way, on my WRT1900AC v1, I see high latencies with my Nexus 6P and Apple iPad Air 2.

Thanks.

-Roger

On Sat, May 21, 2016 at 7:04 AM, yuhhaurlin notifications@github.com wrote:

Does anyone still get high ping Times for the latest driver?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/kaloz/mwlwifi/issues/74#issuecomment-220779531

[bill1228]

Latest build I have seen still have the .17 driver. I am not an accomplished compiler, so I make use of others. Running build by Arokh r49166 which is the .17 driver on my WRT1900AC V1. Don't think that Kong has a build with anything higher then .17 at this time available.

If there is a build with a later driver I would be happy to test.

--bill

[Razerwire]

Does anyone still get high ping Times for the latest driver?

@yuhhaurlin I used to see high latency when running Linux Kernel 4.5> or Windows 10 on my cliënts but the high latency issue seems resolved to me. :)

[yuhhaurlin]

@Razerwire Thanks.

[itrankolov]

I am not @home. I will check it out on Monday.

[mha1der]

Latency from client to router seems to be fine now, but when i ping this client from the router i have a very high ping:

PING 192.168.1.138 (192.168.1.138): 56 data bytes 64 bytes from 192.168.1.138: seq=0 ttl=64 time=189.405 ms 64 bytes from 192.168.1.138: seq=1 ttl=64 time=213.982 ms 64 bytes from 192.168.1.138: seq=2 ttl=64 time=237.432 ms 64 bytes from 192.168.1.138: seq=3 ttl=64 time=261.353 ms 64 bytes from 192.168.1.138: seq=4 ttl=64 time=285.273 ms 64 bytes from 192.168.1.138: seq=5 ttl=64 time=309.227 ms 64 bytes from 192.168.1.138: seq=6 ttl=64 time=128.195 ms 64 bytes from 192.168.1.138: seq=7 ttl=64 time=152.119 ms 64 bytes from 192.168.1.138: seq=8 ttl=64 time=176.089 ms 64 bytes from 192.168.1.138: seq=9 ttl=64 time=1.096 ms 64 bytes from 192.168.1.138: seq=10 ttl=64 time=224.015 ms 64 bytes from 192.168.1.138: seq=11 ttl=64 time=1.074 ms 64 bytes from 192.168.1.138: seq=12 ttl=64 time=275.563 ms 64 bytes from 192.168.1.138: seq=13 ttl=64 time=295.817 ms 64 bytes from 192.168.1.138: seq=14 ttl=64 time=116.632 ms 64 bytes from 192.168.1.138: seq=15 ttl=64 time=138.970 ms 64 bytes from 192.168.1.138: seq=16 ttl=64 time=162.500 ms 64 bytes from 192.168.1.138: seq=17 ttl=64 time=186.835 ms

--- 192.168.1.138 ping statistics --- 18 packets transmitted, 18 packets received, 0% packet loss round-trip min/avg/max = 1.074/186.420/309.227 ms

I have this issue only with one client (MacBook Air 2015).

[yuhhaurlin]

It is possible that the client is running power save mode.

[Chadster766]

@mha1der are you pinging a wireless Mac computer?

[mha1der]

@Chadster766 yes.

If i ping my other Macbook (Pro, 2011) i have only 0,5 - 1,5ms.

[Chadster766]

Some Mac computer like my Mac Mini have a wireless driver issue where incoming pings are very high ping times like you are mentioning.

I was not able to find a solution to my Mac issue. Even updating with a full OSX install didn't solve the issue.

[mha1der]

@Chadster766 thanks, then it probably has nothing to do with the mwlwifi-driver.

[yuhhaurlin]

https://discussions.apple.com/thread/3570949?tstart=0

[mha1der]

@yuhhaurlin thanks.

[MrDoh]

Okay, I've just done some testing using davidc502's 5/21/2016 firmware build on my WRT1900AC. The network latencies of both of the problematic clients here are now in line with where they should be. Less than 1/2 of what they were on previous firmware that I've tested. This looks much better.

I still have a bunch of testing to do, but thanks very much for getting this fixed!

-Roger

On Sat, May 21, 2016 at 4:56 PM, mha1der notifications@github.com wrote:

@yuhhaurlin https://github.com/yuhhaurlin thanks.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/kaloz/mwlwifi/issues/74#issuecomment-220806718

[MrDoh]

Need to add that I'm seeing a kernel log full of these errors now:

[ 5379.158180] ieee80211 phy0: check ba result error 1 [ 5379.163192] ieee80211 phy0: ampdu start error code: -22

I had checked for them before, and only have seen a few, now I see a whole lot.

That can't be good smile.

Thanks.

-Roger

On Sun, May 22, 2016 at 12:22 AM, Roger Vortman rvortman@gmail.com wrote:

Okay, I've just done some testing using davidc502's 5/21/2016 firmware build on my WRT1900AC. The network latencies of both of the problematic clients here are now in line with where they should be. Less than 1/2 of what they were on previous firmware that I've tested. This looks much better.

I still have a bunch of testing to do, but thanks very much for getting this fixed!

-Roger

On Sat, May 21, 2016 at 4:56 PM, mha1der notifications@github.com wrote:

@yuhhaurlin https://github.com/yuhhaurlin thanks.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/kaloz/mwlwifi/issues/74#issuecomment-220806718

[yuhhaurlin]

@MrDoh Please check issue #77.

[MrDoh]

Okay, looks like the messages don't represent a functional error or warning, and will be removed in the next firmware version that I test.

Thanks!

-Roger

On May 22, 2016, at 7:00 PM, yuhhaurlin notifications@github.com wrote:

@MrDoh Please check issue #77.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[itrankolov]

Hi,

Latency issue seems kind of resolved. I mean sometimes it is ok, sometimes it is not. There is something new though ... the below was spit out in dmesg and after that I was not more able to connect to the WiFi network. A reboot was necessary to enable the connection again.

[ 8985.423454] ieee80211 phy1: check ba result err 1(7c:7a:91:2e:a1:b7) [ 8985.430095] ieee80211 phy1: ampdu start error code: -22(7c:7a:91:2e:a1:b7) [ 8985.477124] ieee80211 phy1: check ba result err 1(7c:7a:91:2e:a1:b7) [ 8985.483879] ieee80211 phy1: ampdu start error code: -22(7c:7a:91:2e:a1:b7) [ 8985.528665] ieee80211 phy1: check ba result err 1(7c:7a:91:2e:a1:b7) [ 8985.535838] ieee80211 phy1: ampdu start error code: -22(7c:7a:91:2e:a1:b7) [ 8985.577193] ieee80211 phy1: check ba result err 1(7c:7a:91:2e:a1:b7) [ 8985.583644] ieee80211 phy1: ampdu start error code: -22(7c:7a:91:2e:a1:b7) [ 8985.626168] ieee80211 phy1: check ba result err 1(7c:7a:91:2e:a1:b7) [ 8985.632834] ieee80211 phy1: ampdu start error code: -22(7c:7a:91:2e:a1:b7) [ 8990.717352] ieee80211 phy1: cmd 0x9125=BAStream timed out [ 8990.722824] ieee80211 phy1: return code: 0x1125 [ 8990.727373] ieee80211 phy1: timeout: 0x1125 [ 8990.731625] ieee80211 phy1: destroy ba failed execution [ 9032.624900] ieee80211 phy1: cmd 0x9122=UpdateEncryption timed out [ 9032.631409] ieee80211 phy1: return code: 0x1122 [ 9032.636005] ieee80211 phy1: timeout: 0x1122 [ 9032.640347] ieee80211 phy1: failed execution [ 9032.644729] wlan1: failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-5) [ 9034.704086] ieee80211 phy1: cmd 0x9122=UpdateEncryption timed out [ 9034.710206] ieee80211 phy1: return code: 0x1122 [ 9034.715066] ieee80211 phy1: timeout: 0x1122 [ 9034.719278] ieee80211 phy1: failed execution [ 9034.723625] wlan1: failed to set key (2, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 9036.754035] ieee80211 phy1: cmd 0x9122=UpdateEncryption timed out [ 9036.760155] ieee80211 phy1: return code: 0x1122 [ 9036.764752] ieee80211 phy1: timeout: 0x1122 [ 9036.768962] ieee80211 phy1: failed execution [ 9036.773298] wlan1: failed to remove key (0, 7c:7a:91:2e:a1:b7) from hardware (-5) [ 9040.830413] ieee80211 phy1: cmd 0x9111=SetNewStation timed out [ 9040.836311] ieee80211 phy1: return code: 0x1111 [ 9040.840872] ieee80211 phy1: timeout: 0x1111 [ 9040.845123] ieee80211 phy1: failed execution [ 9043.830689] ieee80211 phy1: cmd 0x8050=broadcast_ssid_enable timed out [ 9043.837285] ieee80211 phy1: return code: 0x0050 [ 9043.841861] ieee80211 phy1: timeout: 0x0050 [ 9043.846061] ieee80211 phy1: failed execution [ 9045.888017] ieee80211 phy1: cmd 0x8127=SetInformationElements timed out [ 9045.894700] ieee80211 phy1: return code: 0x0127 [ 9045.899586] ieee80211 phy1: timeout: 0x0127 [ 9045.904130] ieee80211 phy1: failed execution [ 9047.939785] ieee80211 phy1: cmd 0x801c=80211RadioControl timed out [ 9047.946033] ieee80211 phy1: return code: 0x001c [ 9047.950583] ieee80211 phy1: timeout: 0x001c [ 9047.954827] ieee80211 phy1: failed execution [ 9050.052250] ieee80211 phy1: cmd 0x8126=SetFixedRate timed out [ 9050.058521] ieee80211 phy1: return code: 0x0126 [ 9050.063334] ieee80211 phy1: timeout: 0x0126 [ 9050.067679] ieee80211 phy1: failed execution

[yuhhaurlin]

This is issue #55

[stamak]

I installed 15.05.1 on my WRT1200AC and had the same problem (high ping) but ONLY from my MBP 2015, meanwhile from linux laptop ping was fine.

Yesterday I upgraded mwlwifi to 10.3.0.17-20160523 and now looks like the problem has gone. Thanks so much.

But here are kernel errors:

[ 1917.109644] mwl_fwcmd_check_ba: 6 callbacks suppressed [ 1917.114835] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.121237] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d) [ 1917.170030] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.176475] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d) [ 1917.219848] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.226282] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d) [ 1917.259778] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.266173] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d) [ 1917.309657] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.316056] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d)

As I see @yuhhaurlin has added some debugging and could be interested in this

[MrDoh]

While the longer client latencies have been fixed now, thanks so much for that, I now see these groups of error messages as well after applying the same patch level as mentioned above.

Here's a sample group:

[42727.621096] mwl_fwcmd_check_ba: 24 callbacks suppressed [42727.626471] ieee80211 phy1: check ba result err 1(30:5a:3a:5c:3a:fc) [42727.626512] ieee80211 phy1: ampdu start error code: -22(30:5a:3a:5c:3a:fc) [42727.671849] ieee80211 phy1: check ba result err 1(30:5a:3a:5c:3a:fc) [42727.671891] ieee80211 phy1: ampdu start error code: -22(30:5a:3a:5c:3a:fc) [42727.712401] ieee80211 phy1: check ba result err 1(30:5a:3a:5c:3a:fc) [42727.712433] ieee80211 phy1: ampdu start error code: -22(30:5a:3a:5c:3a:fc) [42727.742423] ieee80211 phy1: check ba result err 1(30:5a:3a:5c:3a:fc) [42727.742451] ieee80211 phy1: ampdu start error code: -22(30:5a:3a:5c:3a:fc) [42727.785182] ieee80211 phy1: check ba result err 1(30:5a:3a:5c:3a:fc) [42727.785212] ieee80211 phy1: ampdu start error code: -22(30:5a:3a:5c:3a:fc)

I am getting these groups of messages at varying intervals. The MAC address 30:5a:3a:5c:3a:fc is the MAC address of a repeater, so I can't see which particular clients could be responsible for this. The clients that I suspect are the ones that originally showed the extra latency, of course. But these messages are now filling my kernel log, again pushing out other error messages that I might need to see.

I could set these two clients into "Airplane" mode for a few hours and see if the messages go away, just haven't had the opportunity to do that yet.

So it doesn't seem like we're quite there.

Thanks very much.

-Roger

On Tue, May 24, 2016 at 8:40 AM, Stanislav Makar notifications@github.com wrote:

I installed 15.05.1 on my WRT1200AC and had the same problem (high ping) but ONLY from my MBP 2015, meanwhile from linux laptop ping was fine.

Yesterday I upgraded mwlwifi to 10.3.0.17-20160523 and now looks like the problem has gone. Thanks so much.

But here are kernel errors:

[ 1917.109644] mwl_fwcmd_check_ba: 6 callbacks suppressed [ 1917.114835] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.121237] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d) [ 1917.170030] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.176475] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d) [ 1917.219848] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.226282] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d) [ 1917.259778] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.266173] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d) [ 1917.309657] ieee80211 phy0: check ba result err 1(ac:bc:32:b3:71:0d) [ 1917.316056] ieee80211 phy0: ampdu start error code: -22(ac:bc:32:b3:71:0d)

As I see @yuhhaurlin https://github.com/yuhhaurlin has added some debugging and could be interested in this

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/kaloz/mwlwifi/issues/74#issuecomment-221312251

[yuhhaurlin]

The kernel by default defines a limit of how many messages will it print before it stops printing for a while. The limit on the number of messages is set in /proc/sys/kernel/printk_ratelimit_burst.
After the above mentioned number of prints, kernel would stop printing for a predefined number of seconds which is set in the file /proc/sys/kerne/printk_ratelimit.

This is depicted in the example module below. The values of the two proc entries are as follows $ cat /proc/sys/kernel/printk_ratelimit_burst 10 $ cat /proc/sys/kernel/printk_ratelimit 5

You can change these values to control the rate to print out these warning messages. I will try to modify the code to check BA is available before asking mac80211 to establish BA. If throughput won't be affected, I will update code.