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:

Is this still happening? Currently, considering on pickup up 2 EAP245 v3's......

@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.

@JojoSocks It's maybe slightly improved, but still not what I'd call usable.

@Alastair799 Yup that's pretty much what I'm seeing. It's better, but still not accebtable.

  @EPerezF 

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.

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.

@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.

  @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.