Devices routinely experience high latency or loss of connection

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Devices routinely experience high latency or loss of connection

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Devices routinely experience high latency or loss of connection
Devices routinely experience high latency or loss of connection
2020-06-14 07:59:51 - last edited 2020-06-18 13:55:15
Model: EAP245  
Hardware Version: V3
Firmware Version: 2.4.0

I've had 2 x EAP245 running for close to a year now, and they've largely been working well. There seem to be some parts of the house with signal issues (likely due to concrete walls with steel), but on the whole, great. The APs are plugged into a PoE switch, along with 4 other PoE devices (cameras). No issues with stability there.

 

For the past week or so, I've been experiencing the following on wireless clients (iPhones):

- High latency when viewing websites

- Although connected to wifi, no internet activity loads

 

To monitor this, I used ping on a laptop (connected via Ethernet).

- Pinging the router: < 1 ms, very little fluctuation

- Pinging the AP my phone is connected to: < 1 ms, very little fluctuation

- Pinging my phone (while very close to the AP, -45 dBm):

64 bytes from 192.168.100.27: icmp_seq=3384 ttl=64 time=105.526 ms
64 bytes from 192.168.100.27: icmp_seq=3385 ttl=64 time=4.183 ms
64 bytes from 192.168.100.27: icmp_seq=3386 ttl=64 time=41.757 ms
64 bytes from 192.168.100.27: icmp_seq=3387 ttl=64 time=2.169 ms
64 bytes from 192.168.100.27: icmp_seq=3388 ttl=64 time=7.743 ms
64 bytes from 192.168.100.27: icmp_seq=3389 ttl=64 time=109.487 ms
64 bytes from 192.168.100.27: icmp_seq=3390 ttl=64 time=27.620 ms
64 bytes from 192.168.100.27: icmp_seq=3391 ttl=64 time=45.689 ms
64 bytes from 192.168.100.27: icmp_seq=3392 ttl=64 time=3.790 ms
64 bytes from 192.168.100.27: icmp_seq=3393 ttl=64 time=8.903 ms
64 bytes from 192.168.100.27: icmp_seq=3394 ttl=64 time=7.709 ms
64 bytes from 192.168.100.27: icmp_seq=3395 ttl=64 time=2.199 ms
64 bytes from 192.168.100.27: icmp_seq=3396 ttl=64 time=3.042 ms
64 bytes from 192.168.100.27: icmp_seq=3397 ttl=64 time=13.931 ms
Request timeout for icmp_seq 3418
Request timeout for icmp_seq 3419
Request timeout for icmp_seq 3420
Request timeout for icmp_seq 3421
Request timeout for icmp_seq 3422
Request timeout for icmp_seq 3423
Request timeout for icmp_seq 3424
Request timeout for icmp_seq 3425
Request timeout for icmp_seq 3426
Request timeout for icmp_seq 3427
Request timeout for icmp_seq 3428
Request timeout for icmp_seq 3429
Request timeout for icmp_seq 3430
Request timeout for icmp_seq 3431
Request timeout for icmp_seq 3432
64 bytes from 192.168.100.27: icmp_seq=3425 ttl=64 time=8048.897 ms
64 bytes from 192.168.100.27: icmp_seq=3426 ttl=64 time=7053.987 ms
64 bytes from 192.168.100.27: icmp_seq=3427 ttl=64 time=6063.000 ms
Request timeout for icmp_seq 3436
Request timeout for icmp_seq 3437
Request timeout for icmp_seq 3438
Request timeout for icmp_seq 3439
64 bytes from 192.168.100.27: icmp_seq=3434 ttl=64 time=6871.918 ms
64 bytes from 192.168.100.27: icmp_seq=3435 ttl=64 time=5873.085 ms
64 bytes from 192.168.100.27: icmp_seq=3436 ttl=64 time=4872.611 ms
64 bytes from 192.168.100.27: icmp_seq=3437 ttl=64 time=3869.003 ms
64 bytes from 192.168.100.27: icmp_seq=3438 ttl=64 time=2993.016 ms
64 bytes from 192.168.100.27: icmp_seq=3441 ttl=64 time=6.076 ms
64 bytes from 192.168.100.27: icmp_seq=3442 ttl=64 time=4.204 ms
64 bytes from 192.168.100.27: icmp_seq=3443 ttl=64 time=9.332 ms
64 bytes from 192.168.100.27: icmp_seq=3444 ttl=64 time=8.039 ms
64 bytes from 192.168.100.27: icmp_seq=3445 ttl=64 time=222.486 ms
64 bytes from 192.168.100.27: icmp_seq=3446 ttl=64 time=76.731 ms
64 bytes from 192.168.100.27: icmp_seq=3447 ttl=64 time=2.381 ms
64 bytes from 192.168.100.27: icmp_seq=3448 ttl=64 time=9.920 ms
64 bytes from 192.168.100.27: icmp_seq=3449 ttl=64 time=2.270 ms
64 bytes from 192.168.100.27: icmp_seq=3450 ttl=64 time=2.549 ms
64 bytes from 192.168.100.27: icmp_seq=3451 ttl=64 time=174.539 ms
64 bytes from 192.168.100.27: icmp_seq=3452 ttl=64 time=97.925 ms
64 bytes from 192.168.100.27: icmp_seq=3453 ttl=64 time=2.434 ms
64 bytes from 192.168.100.27: icmp_seq=3454 ttl=64 time=2.345 ms
64 bytes from 192.168.100.27: icmp_seq=3455 ttl=64 time=2.877 ms
64 bytes from 192.168.100.27: icmp_seq=3456 ttl=64 time=2.211 ms
64 bytes from 192.168.100.27: icmp_seq=3457 ttl=64 time=17.703 ms
64 bytes from 192.168.100.27: icmp_seq=3458 ttl=64 time=5.383 ms
64 bytes from 192.168.100.27: icmp_seq=3459 ttl=64 time=2.192 ms
64 bytes from 192.168.100.27: icmp_seq=3460 ttl=64 time=18.042 ms
64 bytes from 192.168.100.27: icmp_seq=3461 ttl=64 time=2.464 ms
64 bytes from 192.168.100.27: icmp_seq=3462 ttl=64 time=8.449 ms
64 bytes from 192.168.100.27: icmp_seq=3463 ttl=64 time=2.330 ms
64 bytes from 192.168.100.27: icmp_seq=3464 ttl=64 time=7.009 ms
64 bytes from 192.168.100.27: icmp_seq=3465 ttl=64 time=2.058 ms

 

One case see that the pings are fluctuating a lot, AND there are periods where the device doesn't respond. All the while, it was open & unlocked. Here's the summary:

3850 packets transmitted, 2811 packets received, 27.0% packet loss
round-trip min/avg/max/stddev = 1.604/1071.133/37034.517/4097.303 ms

 

I've tried the following to remedy this:

- Removed the other PoE devices from the switch, to see if it was overloaded. Made no difference.

- Added the PoE injector to the AP. Made no difference.

- Changed wifi channels for the 2.4GHz radio. This is the best I could get it: 

 

(Since taking this screenshot a few minutes ago, the 2.4GHz utilisation has jumped to 28%. Coincidence?)

 

I'm rather stumped. Does anyone have any suggestions?

  0      
  0      
#1
Options
1 Accepted Solution
Re:Devices routinely experience high latency or loss of connection-Solution
2020-06-14 15:09:04 - last edited 2020-06-18 13:55:15

Hi @JeremyHiggs,

 

Why is your iPhone on the 2.4GHz channel?  I realize this doesn't answer your question, but for optimal speeds it should be on the 5.8GHz channel.

 

Are you using Omada or OC-200?

 

Some general recommendations:

 

1) Use separate SSID's for 2.4 and 5.8GHz radios -- join your phone to ONLY the 5.8GHz SSID.

2) Disable band steering

3) Disable air time fairness

4) Disable MESH (if an option, and you're not using it)

5) Set 2.4GHz radios to 20MHz, 802.11 b,g,n, WPA2-PSK, use separate channels for each 1, 6, or 11.  Set transmit power to Medium

6) Set 5.8GHz radios to 80MHz (NOT 20/40/80), 802.11 n,ac, WPA2-PSK, use separate channels for each 36, 149. Set transmit power to Medium

7) Enable fast roaming (requires Omada)

8) check/replace your Ethernet cables

 

Always try pinging a PC, router, internet from your phone, not from a device on your network to your phone.  Mobile device do a lot of power saving stuff (even then the screen is unlocked) and may not respond to a ping right away.  Also run speed tests from your phone -- Ookla, SpeedSmart, Fast.com

 

Utilization will change dynamically as you are running tests.  Speed tests will increase utilization as much as 50-70% -- this is normal.  What you want to make sure of is that utilization is low (generally <=20-30%) when devices are idle.  Often it will be only 10-15% unless you are seeing a lot of interference from your neighbors or your own, other, AP's.

 

Do you see these performance issues on BOTH AP's.  Or is one better than the other?  If they are both doing it -- there must be some factor that is in common to both.  Bad switch, bad cables, new firmware, cable to router, etc.

 

-Jonathan

Recommended Solution
  0  
  0  
#2
Options
7 Reply
Re:Devices routinely experience high latency or loss of connection-Solution
2020-06-14 15:09:04 - last edited 2020-06-18 13:55:15

Hi @JeremyHiggs,

 

Why is your iPhone on the 2.4GHz channel?  I realize this doesn't answer your question, but for optimal speeds it should be on the 5.8GHz channel.

 

Are you using Omada or OC-200?

 

Some general recommendations:

 

1) Use separate SSID's for 2.4 and 5.8GHz radios -- join your phone to ONLY the 5.8GHz SSID.

2) Disable band steering

3) Disable air time fairness

4) Disable MESH (if an option, and you're not using it)

5) Set 2.4GHz radios to 20MHz, 802.11 b,g,n, WPA2-PSK, use separate channels for each 1, 6, or 11.  Set transmit power to Medium

6) Set 5.8GHz radios to 80MHz (NOT 20/40/80), 802.11 n,ac, WPA2-PSK, use separate channels for each 36, 149. Set transmit power to Medium

7) Enable fast roaming (requires Omada)

8) check/replace your Ethernet cables

 

Always try pinging a PC, router, internet from your phone, not from a device on your network to your phone.  Mobile device do a lot of power saving stuff (even then the screen is unlocked) and may not respond to a ping right away.  Also run speed tests from your phone -- Ookla, SpeedSmart, Fast.com

 

Utilization will change dynamically as you are running tests.  Speed tests will increase utilization as much as 50-70% -- this is normal.  What you want to make sure of is that utilization is low (generally <=20-30%) when devices are idle.  Often it will be only 10-15% unless you are seeing a lot of interference from your neighbors or your own, other, AP's.

 

Do you see these performance issues on BOTH AP's.  Or is one better than the other?  If they are both doing it -- there must be some factor that is in common to both.  Bad switch, bad cables, new firmware, cable to router, etc.

 

-Jonathan

Recommended Solution
  0  
  0  
#2
Options
Re:Devices routinely experience high latency or loss of connection
2020-06-14 15:41:01

iPhone on 5GHz: I've been wondering why it defaults to 2.4GHz, too. It's been like that for a while, and I figured it was something particular to the iPhone wifi stack, rather than Omada. I'll try pushing it to a separate 5GHz SSID and see if that makes a difference.

 

Omada/OC-200: Omada running on a Raspberry Pi 3. AFAIK, this shouldn't affect clients on the AP, and is only used for fast roaming... right?

 

Roaming: Fast Roaming, Dual Band 11k Report and Force-disassociation enabled.

 

Mesh: not using it and it's disabled. All APs connected using ethernet cables.

 

Band steering & airtime fairness: aren't these useful for the wifi clients?

 

Ping from iPhone: pinging the router from the phone:

82 packets transmitted, 82 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.237/14.489/101.669/16.377 ms

 

I'll try what you've suggested and see whether the results are any better! Thanks

  0  
  0  
#3
Options
Re:Devices routinely experience high latency or loss of connection
2020-06-14 16:03:13 - last edited 2020-06-14 16:04:21

Hi @JeremyHiggs,

 

"AFAIK, this shouldn't affect clients on the AP, and is only used for fast roaming... right?"

Correct.  Only used for Fast Roaming and dynamic MESH reconfiguration (which you're not using).  I don't think it is used for band steering.

 

"Roaming: Fast Roaming, Dual Band 11k Report and Force-disassociation enabled."

Correct.  Though Dual Band report can be disabled if not using band steering.

 

"Band steering & airtime fairness: aren't these useful for the wifi clients?"


Definately turn off airtime fairness.  This relatively new wifi feature is very buggy and not all clients support it / support it well.  Some clients like HP Wifi Printers, some Nest devices may not connect at all with it enabled.  Airtime fairness is only potentially relevent if you have more than 30-50 wifi clients per AP, and then, like I said, it often causes more problems than it helps
 

Band steering is similar.  It's supposed to help / make things easier.  But like a lot of automation it doesn't always work the way you would expect, or at all.  I have experimented with it on my iphone XSM and it seems to more or less work correctly.  But for troubleshooting especially, it's best to turn it off and use separate SSID's for 2.4 and 5.8.  Then join your clients to one or the other -- not both.  This way you can control which devices are connected to what and know for sure what speeds / airlink rates they should be doing.

 

-Jonathan

  0  
  0  
#4
Options
Re:Devices routinely experience high latency or loss of connection
2020-06-18 13:55:06
I wanted to update on this. With the separate 5GHz network, it’s been working great! If the house was much larger and the reception wasn’t great (such that 2.4GHz would be needed), maybe it would be an issue, but it’s been great in this setting. I only wish that band steering would work better!
  0  
  0  
#5
Options
Re:Devices routinely experience high latency or loss of connection
2020-06-18 14:27:38

Hi @JeremyHiggs,

 

Great to hear things are working better for you.  Yes, I have found when testing band steering that when the mobile device is on the edge of good 5G coverage it "cannot device" whether it wants to be on 5.8 or 2.4.  It tends to flip back and forth, and during this time I have experienced high latency and data stalls / stutters.

 

By forcing clients onto 5G only (with a separate SSID), the device has no choice to negotiation slower and slower air link rates with the AP as signal levels decrease.  This behavior seems much more predictable in it's behavior and while speeds are impacted, latency more or less stays the same -- until the STA RSSI falls to much and there is a lot of packet re-transmission.

 

I worried about this same thing as well hoping that handing of to 2.4GHz would help me outside.  But, ultimately I just purchased an outdoor unit instead (in addition) and now have 5G coverage inside and outside my house.

 

For my phone it doesn't really matter that much anyway, as it transitions to cellular when it eventually looses Wifi signal outside.

 

-Jonathan

  1  
  1  
#6
Options
Re:Devices routinely experience high latency or loss of connection
2020-08-02 11:32:04 - last edited 2020-08-02 11:32:53

@JeremyHiggs  @JSchnee21 

 

Every now and then I experience the same on my 2 * EAP 225 (v.3, current latest 2.7.0 Firmware) with OC2000 setup
I know most fingerpointing goes to apple for their wifi setup (https://community.tp-link.com/en/business/forum/topic/150813?page=2) and I had success in a IOS reset as in article 150813 but the other day practically all my IOS devices were reconnecting constantly. Reboot of EAP's did not resolve

So I stumbled on this article - I split my 2.4Ghz and 5Ghz which does seem to bring resolve at this point. 

I had airtime fairness and mesh on (but do not use mesh) which I disabled too
Still wondering if/what TP Link can do to "fix" this. 

if I may ; Question @ Jonathan ; you think its worth a try to combine the bands again while keeping the other options as you state ?
And what is your opinion on WMM - as far as I can see its needed to get any decent ~ high ~ connection speeds

 

Thank you !

  0  
  0  
#7
Options
Re:Devices routinely experience high latency or loss of connection
2020-08-02 17:56:42

@Arjan,

 

WMM is required for 802.11ac (and possibly for 802.11n) so you definately want this to be enabled.

 

Whether or not Band Steering works, or works well, is a more complicated issue.  It's not really anyone's fault, per se, but band steering as a technology just doesn't work that well.  Different vendors implement it differently, and I see a lot of complaints on Reddit and other places with people having wireless issues and it is often band steering related.

 

But you can always experiment with it, just create a third wireless SSID and enable it to use both the 2.4 and 5.8GHz radios.  Then enable band steering in the OC200.

 

Finally, connect select wireless devices (STA's) to just the one SSID for testing.

 

I do this myself.  I have the following SSID's at home:

myssid               (2.4GHz only)

myssid_5GHz    (5.8GHz only)

myssid_dual      (both 2.4GHz and 5.8GHz w/Band steering)

 

I've tested my iPhone XSM on the "myssid_dual" SSID.  The band steering "works" per se, but at the coverage age of the 5.8GHz signal it's flaky, bounces back and forth, and displays high latency until you get far enough away that the phone doesn't see the 5.8GHz network anymore.

 

-Jonathan

 

  0  
  0  
#8
Options