EAP245 Lag spikes and packet loss
EAP245 Lag spikes and packet loss
Hi!
I have 2 EAP245 connected to a router which also works as DHCP. All is managed by a Windows PC running Omada Controller and connected directly to the router.
The first AP is in the rooms part of the house. There are around 11 to 15 devices connected to it. Mostly laptops, smartphones and tablets and a smart TV.
The second AP is on the living room part of the house. There are 2 to 4 devices connected to it. A console, a printer and sometimes a laptop or smartphone.
Regardless of the distance between the devices and the AP I am having several lag spikes every 5 to 10 seconds and can range from 200 up to even 20000ms.
Here's a graph of the lag spikes pinging to google.com from a MacBook Pro.
Here are the ping results from a MacBook Pro to: 192.168.100.115 (the rooms AP), 192.168.100.1 (the Router) and 192.168.100.116 (the living room AP). Notice how the 2 lag spikes are separated by 10 seconds.
Sometimes the packets get stuck and suddenly appear all in one go with a massive latency time.
I have already tested the connectivity between the APs and the router and it is fine. pinging from the router or the PC to the APs doesn't show any lag spike so it must be an issue with the WiFi part of the network.
Any suggestions?
Thanks!!
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
I'm having the same issue with macbook pro, EAP225s. So far I've tried 5.0.3, 5.0.4, 5.0.7, the most recent one seems better than the others but not perfect.
Any help appreciated.
5.0.7 looks like this with some increase in latency:
64 bytes from 195.216.16.129: icmp_seq=1406 ttl=56 time=19.204 ms
64 bytes from 195.216.16.129: icmp_seq=1407 ttl=56 time=17.888 ms
64 bytes from 195.216.16.129: icmp_seq=1408 ttl=56 time=22.970 ms
64 bytes from 195.216.16.129: icmp_seq=1409 ttl=56 time=20.921 ms
64 bytes from 195.216.16.129: icmp_seq=1410 ttl=56 time=36.148 ms
64 bytes from 195.216.16.129: icmp_seq=1411 ttl=56 time=62.532 ms
64 bytes from 195.216.16.129: icmp_seq=1412 ttl=56 time=21.707 ms
64 bytes from 195.216.16.129: icmp_seq=1413 ttl=56 time=45.780 ms
64 bytes from 195.216.16.129: icmp_seq=1414 ttl=56 time=276.244 ms
64 bytes from 195.216.16.129: icmp_seq=1415 ttl=56 time=448.552 ms
64 bytes from 195.216.16.129: icmp_seq=1416 ttl=56 time=960.684 ms
64 bytes from 195.216.16.129: icmp_seq=1417 ttl=56 time=3784.449 ms
64 bytes from 195.216.16.129: icmp_seq=1418 ttl=56 time=3805.509 ms
64 bytes from 195.216.16.129: icmp_seq=1419 ttl=56 time=2816.485 ms
64 bytes from 195.216.16.129: icmp_seq=1420 ttl=56 time=1826.058 ms
64 bytes from 195.216.16.129: icmp_seq=1421 ttl=56 time=836.264 ms
64 bytes from 195.216.16.129: icmp_seq=1422 ttl=56 time=43.127 ms
64 bytes from 195.216.16.129: icmp_seq=1423 ttl=56 time=22.939 ms
64 bytes from 195.216.16.129: icmp_seq=1424 ttl=56 time=17.799 ms
64 bytes from 195.216.16.129: icmp_seq=1425 ttl=56 time=18.392 ms
But nowhere near as bad as 5.0.4 where I'd see bigger gaps and lost packets:
- Copy Link
- Report Inappropriate Content
Is this still happening? Currently, considering on pickup up 2 EAP245 v3's......
- Copy Link
- Report Inappropriate Content
@JojoSocks it seems to be resolved by upgrading my macOS to Monterey (12.2) but I'm away so didn't get a huge period to prove it.
- Copy Link
- Report Inappropriate Content
@JojoSocks It's maybe slightly improved, but still not what I'd call usable.
- Copy Link
- Report Inappropriate Content
@Alastair799 Yup that's pretty much what I'm seeing. It's better, but still not accebtable.
- Copy Link
- Report Inappropriate Content
Hey, just wanted to say that i'm also facing this issue.
But my circumstances differ a bit, i'm using two EAP 235 Wall APs, one at every floor, configured via omada software controller, also i don't use any apple computers.
My connection is unstable (massive lags while streaming or video calls for example) and i can reproduce those ping lag Spikes.
Here while pinging my router:
64 Bytes von 192.168.178.1: icmp_seq=1828 ttl=64 Zeit=2.88 ms
64 Bytes von 192.168.178.1: icmp_seq=1829 ttl=64 Zeit=2.32 ms
64 Bytes von 192.168.178.1: icmp_seq=1830 ttl=64 Zeit=23.9 ms
64 Bytes von 192.168.178.1: icmp_seq=1831 ttl=64 Zeit=49.2 ms
64 Bytes von 192.168.178.1: icmp_seq=1832 ttl=64 Zeit=74.9 ms
64 Bytes von 192.168.178.1: icmp_seq=1833 ttl=64 Zeit=100 ms
64 Bytes von 192.168.178.1: icmp_seq=1834 ttl=64 Zeit=2.34 ms
64 Bytes von 192.168.178.1: icmp_seq=1835 ttl=64 Zeit=2.81 ms
64 Bytes von 192.168.178.1: icmp_seq=1836 ttl=64 Zeit=3.22 ms
64 Bytes von 192.168.178.1: icmp_seq=1837 ttl=64 Zeit=2.85 ms
64 Bytes von 192.168.178.1: icmp_seq=1838 ttl=64 Zeit=3.02 ms
64 Bytes von 192.168.178.1: icmp_seq=1839 ttl=64 Zeit=3.22 ms
64 Bytes von 192.168.178.1: icmp_seq=1840 ttl=64 Zeit=2.87 ms
64 Bytes von 192.168.178.1: icmp_seq=1841 ttl=64 Zeit=3.41 ms
64 Bytes von 192.168.178.1: icmp_seq=1842 ttl=64 Zeit=32.7 ms
64 Bytes von 192.168.178.1: icmp_seq=1843 ttl=64 Zeit=3.35 ms
64 Bytes von 192.168.178.1: icmp_seq=1844 ttl=64 Zeit=13.8 ms
64 Bytes von 192.168.178.1: icmp_seq=1845 ttl=64 Zeit=54.9 ms
64 Bytes von 192.168.178.1: icmp_seq=1846 ttl=64 Zeit=80.8 ms
64 Bytes von 192.168.178.1: icmp_seq=1847 ttl=64 Zeit=106 ms
64 Bytes von 192.168.178.1: icmp_seq=1848 ttl=64 Zeit=134 ms
64 Bytes von 192.168.178.1: icmp_seq=1849 ttl=64 Zeit=3.08 ms
64 Bytes von 192.168.178.1: icmp_seq=1850 ttl=64 Zeit=4.37 ms
64 Bytes von 192.168.178.1: icmp_seq=1851 ttl=64 Zeit=2.83 ms
64 Bytes von 192.168.178.1: icmp_seq=1852 ttl=64 Zeit=3.94 ms
64 Bytes von 192.168.178.1: icmp_seq=1853 ttl=64 Zeit=3.19 ms
64 Bytes von 192.168.178.1: icmp_seq=1854 ttl=64 Zeit=4.03 ms
64 Bytes von 192.168.178.1: icmp_seq=1855 ttl=64 Zeit=3.85 ms
64 Bytes von 192.168.178.1: icmp_seq=1856 ttl=64 Zeit=3.03 ms
64 Bytes von 192.168.178.1: icmp_seq=1857 ttl=64 Zeit=80.0 ms
64 Bytes von 192.168.178.1: icmp_seq=1858 ttl=64 Zeit=2.98 ms
64 Bytes von 192.168.178.1: icmp_seq=1859 ttl=64 Zeit=152 ms
64 Bytes von 192.168.178.1: icmp_seq=1860 ttl=64 Zeit=2.24 ms
64 Bytes von 192.168.178.1: icmp_seq=1861 ttl=64 Zeit=15.1 ms
Even if i ping the access point i'm connected to the issues persists:
64 Bytes von 192.168.178.36: icmp_seq=15 ttl=64 Zeit=1.88 ms
64 Bytes von 192.168.178.36: icmp_seq=16 ttl=64 Zeit=1.81 ms
64 Bytes von 192.168.178.36: icmp_seq=17 ttl=64 Zeit=28.8 ms
64 Bytes von 192.168.178.36: icmp_seq=18 ttl=64 Zeit=121 ms
64 Bytes von 192.168.178.36: icmp_seq=19 ttl=64 Zeit=147 ms
64 Bytes von 192.168.178.36: icmp_seq=20 ttl=64 Zeit=1.96 ms
64 Bytes von 192.168.178.36: icmp_seq=21 ttl=64 Zeit=1.76 ms
64 Bytes von 192.168.178.36: icmp_seq=22 ttl=64 Zeit=21.0 ms
64 Bytes von 192.168.178.36: icmp_seq=23 ttl=64 Zeit=2.02 ms
64 Bytes von 192.168.178.36: icmp_seq=24 ttl=64 Zeit=1.85 ms
64 Bytes von 192.168.178.36: icmp_seq=25 ttl=64 Zeit=2.05 ms
64 Bytes von 192.168.178.36: icmp_seq=26 ttl=64 Zeit=2.06 ms
64 Bytes von 192.168.178.36: icmp_seq=27 ttl=64 Zeit=1.87 ms
64 Bytes von 192.168.178.36: icmp_seq=28 ttl=64 Zeit=1.98 ms
64 Bytes von 192.168.178.36: icmp_seq=29 ttl=64 Zeit=2.54 ms
64 Bytes von 192.168.178.36: icmp_seq=30 ttl=64 Zeit=2.28 ms
64 Bytes von 192.168.178.36: icmp_seq=31 ttl=64 Zeit=42.9 ms
64 Bytes von 192.168.178.36: icmp_seq=32 ttl=64 Zeit=1.93 ms
64 Bytes von 192.168.178.36: icmp_seq=33 ttl=64 Zeit=34.0 ms
64 Bytes von 192.168.178.36: icmp_seq=34 ttl=64 Zeit=60.7 ms
64 Bytes von 192.168.178.36: icmp_seq=35 ttl=64 Zeit=101 ms
64 Bytes von 192.168.178.36: icmp_seq=36 ttl=64 Zeit=127 ms
64 Bytes von 192.168.178.36: icmp_seq=37 ttl=64 Zeit=153 ms
64 Bytes von 192.168.178.36: icmp_seq=38 ttl=64 Zeit=1.96 ms
64 Bytes von 192.168.178.36: icmp_seq=39 ttl=64 Zeit=3.75 ms
64 Bytes von 192.168.178.36: icmp_seq=40 ttl=64 Zeit=1.74 ms
At the time of the tests i was the only one actively using the wifi (there are some devices connected, but no one's interacting with those devices).
Omada controller shows a lot of dropped and retried packets:
This issue is so annoying, hope we can get some help from official tplink support.
- Copy Link
- Report Inappropriate Content
Just to provide an update, my EAP-225's are now all on 5.7, my MacBookPro is now on Monterrey 12.2.1 and the problem has gone away.
I've got rock solid ping performance and no video conferencing dropouts so well worth upgrading MacOS.
- Copy Link
- Report Inappropriate Content
@Sweep What os are you running, and what network card brand? Maybe we can narrow this down a bit?
@Alastair799 Unfortunately all the Macs we have that are giving issues are unable to upgrade to Monterrey. Oddly enough none of the newer Macs ever had the issue even on older releases.
- Copy Link
- Report Inappropriate Content
@nixcamic Hi, just reading through the release notes of the EAP660HD(EU)_V1_1.1.1 firmware it states: Fixed the bug that Tx packet loss rate and error rate of about 25% under 5GHz.
Did you happen to check if this works? Seems like tp-link found something.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 1
Views: 6338
Replies: 20