R500 Large Ping & unstable path to client

  • 1
  • Question
  • Updated 1 month ago
Am seeing massive "ping delays & drops to  clients  under R500 AP.. .sometimes.

Basically the APs' operate in a very polluted hostile environment.


Client is windows ,traffic is next to nothing.


172.20.1.121

802.11b/g/n
-66 dBm
46 dB
Excellent



ping to the AP


ping 172.20.0.6
PING 172.20.0.6 (172.20.0.6): 56 data bytes
64 bytes from 172.20.0.6: icmp_seq=0 ttl=63 time=6.982 ms
64 bytes from 172.20.0.6: icmp_seq=1 ttl=63 time=6.812 ms
64 bytes from 172.20.0.6: icmp_seq=2 ttl=63 time=6.685 ms
64 bytes from 172.20.0.6: icmp_seq=3 ttl=63 time=6.707 ms

ping to the client

64 bytes from 172.20.1.63: icmp_seq=967 ttl=63 time=108.552 ms
Request timeout for icmp_seq 968
Request timeout for icmp_seq 969
Request timeout for icmp_seq 970
64 bytes from 172.20.1.63: icmp_seq=969 ttl=63 time=2324.465 ms
64 bytes from 172.20.1.63: icmp_seq=970 ttl=63 time=1399.448 ms
64 bytes from 172.20.1.63: icmp_seq=971 ttl=63 time=395.006 ms
64 bytes from 172.20.1.63: icmp_seq=972 ttl=63 time=528.905 ms
64 bytes from 172.20.1.63: icmp_seq=973 ttl=63 time=212.009 ms
64 bytes from 172.20.1.63: icmp_seq=974 ttl=63 time=757.311 ms
64 bytes from 172.20.1.63: icmp_seq=975 ttl=63 time=276.469 ms
64 bytes from 172.20.1.63: icmp_seq=976 ttl=63 time=1269.509 ms
64 bytes from 172.20.1.63: icmp_seq=977 ttl=63 time=267.469 ms
64 bytes from 172.20.1.63: icmp_seq=978 ttl=63 time=1972.205 ms
64 bytes from 172.20.1.63: icmp_seq=979 ttl=63 time=970.159 ms
64 bytes from 172.20.1.63: icmp_seq=980 ttl=63 time=55.247 ms
64 bytes from 172.20.1.63: icmp_seq=981 ttl=63 time=394.299 ms
64 bytes from 172.20.1.63: icmp_seq=982 ttl=63 time=617.992 ms
64 bytes from 172.20.1.63: icmp_seq=983 ttl=63 time=536.143 ms
64 bytes from 172.20.1.63: icmp_seq=984 ttl=63 time=48.595 ms
64 bytes from 172.20.1.63: icmp_seq=985 ttl=63 time=1613.516 ms





My main issue is why it is classed as "excellent"?

is there any way to get counters on resends/drops, that sort of thing?
packet loss?








Photo of Caveman

Caveman

  • 51 Posts
  • 6 Reply Likes

Posted 1 month ago

  • 1
Photo of Syamantak Omer

Syamantak Omer, Official Rep

  • 551 Posts
  • 175 Reply Likes
Hi Caveman,

It is classified as per the signal strength of the connected client, but not the send/receive/drops frames.

Regards,
Syamantak Omer
(Edited)
Photo of Caveman

Caveman

  • 51 Posts
  • 6 Reply Likes
how can i get this information,
because i'm also seeing this following stupidity as well, something i documented previously, but it was never this bad...


A totally STATIC computer in an EMPTY office, with no partitioning or staff or anything moving about after hours.....
Not even any security staff......

s

Photo of Syamantak Omer

Syamantak Omer, Official Rep

  • 505 Posts
  • 162 Reply Likes
If overlapping between the APs is very high, sometimes client may get confused and unable to decide which AP is best, thus frequently roams between nearest APs.

Please note that roaming is totally a client UE decision and its driver configuration.

You can remediate this by changing BSS minrate to 12Mbps in WLAN setting and see if it fixes the issue.

Also it is worth checking if this system has a USB 3.0 device connected to it, because client is connected on 2.4 G radio and USB 3.0 devices cause interference on 2.4 G radio.

Regards,
Syamantak Omer
Photo of Caveman

Caveman

  • 51 Posts
  • 6 Reply Likes
I would say not, it is the AP to decide IF it accepts a client on a new AP, that is hopefully WHY you have a controller.....
It should still up to the AP to tell the client to get lost , if it considers there is no gain in changing AP  ESP.... as the AP can be set for a client limit....
(Edited)