High ping on 802.11/ac devices

I am have having a weird issue where the ping on ac devices is incredibility high especially when compared to n devices on the network.

For example, below is from my main computer which uses an Intel 7260 ac wireless card:

PING enyo.network.dev (192.168.2.5): 56 data bytes
64 bytes from 192.168.2.5: icmp_seq=0 ttl=64 time=0.824 ms
64 bytes from 192.168.2.5: icmp_seq=1 ttl=64 time=85.663 ms
64 bytes from 192.168.2.5: icmp_seq=2 ttl=64 time=96.012 ms
64 bytes from 192.168.2.5: icmp_seq=3 ttl=64 time=105.124 ms
64 bytes from 192.168.2.5: icmp_seq=4 ttl=64 time=37.823 ms
64 bytes from 192.168.2.5: icmp_seq=5 ttl=64 time=134.227 ms
64 bytes from 192.168.2.5: icmp_seq=6 ttl=64 time=342.808 ms
64 bytes from 192.168.2.5: icmp_seq=7 ttl=64 time=262.857 ms
64 bytes from 192.168.2.5: icmp_seq=8 ttl=64 time=101.188 ms
64 bytes from 192.168.2.5: icmp_seq=9 ttl=64 time=88.511 ms

--- enyo.network.dev ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.824/125.504/342.808/97.071 ms

And this is from my phone which also uses 802.11/ac:

PING 192.168.2.7 (192.168.2.7): 56 data bytes
64 bytes from 192.168.2.7: icmp_seq=0 ttl=64 time=83.417 ms
64 bytes from 192.168.2.7: icmp_seq=1 ttl=64 time=51.472 ms
64 bytes from 192.168.2.7: icmp_seq=2 ttl=64 time=13.581 ms
64 bytes from 192.168.2.7: icmp_seq=3 ttl=64 time=10.373 ms
64 bytes from 192.168.2.7: icmp_seq=4 ttl=64 time=10.304 ms
64 bytes from 192.168.2.7: icmp_seq=5 ttl=64 time=17.725 ms
64 bytes from 192.168.2.7: icmp_seq=6 ttl=64 time=29.085 ms
64 bytes from 192.168.2.7: icmp_seq=7 ttl=64 time=40.047 ms
64 bytes from 192.168.2.7: icmp_seq=8 ttl=64 time=42.426 ms
64 bytes from 192.168.2.7: icmp_seq=9 ttl=64 time=51.390 ms

--- 192.168.2.7 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.304/34.982/83.417/22.301 ms

As you can see the ping is quite high and should be much lower, for comparison below are some ping stats from n devices on the network.

This is from my mothers computer which uses 802.11/n on the 5GHz band:

PING 192.168.2.36 (192.168.2.36): 56 data bytes
64 bytes from 192.168.2.36: icmp_seq=0 ttl=128 time=0.817 ms
64 bytes from 192.168.2.36: icmp_seq=1 ttl=128 time=0.857 ms
64 bytes from 192.168.2.36: icmp_seq=2 ttl=128 time=0.873 ms
64 bytes from 192.168.2.36: icmp_seq=3 ttl=128 time=0.755 ms
64 bytes from 192.168.2.36: icmp_seq=4 ttl=128 time=0.793 ms
64 bytes from 192.168.2.36: icmp_seq=5 ttl=128 time=0.841 ms
64 bytes from 192.168.2.36: icmp_seq=6 ttl=128 time=0.891 ms
64 bytes from 192.168.2.36: icmp_seq=7 ttl=128 time=0.764 ms
64 bytes from 192.168.2.36: icmp_seq=8 ttl=128 time=0.828 ms
64 bytes from 192.168.2.36: icmp_seq=9 ttl=128 time=0.840 ms

--- 192.168.2.36 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.755/0.826/0.891/0.042 ms

And this is from one of my servers which uses 802.11/n but on the 2.4Gz band:

PING drake.network.dev (192.168.2.6): 56 data bytes
64 bytes from 192.168.2.6: icmp_seq=0 ttl=64 time=1.799 ms
64 bytes from 192.168.2.6: icmp_seq=1 ttl=64 time=1.910 ms
64 bytes from 192.168.2.6: icmp_seq=2 ttl=64 time=1.802 ms
64 bytes from 192.168.2.6: icmp_seq=3 ttl=64 time=1.858 ms
64 bytes from 192.168.2.6: icmp_seq=4 ttl=64 time=1.734 ms
64 bytes from 192.168.2.6: icmp_seq=5 ttl=64 time=1.726 ms
64 bytes from 192.168.2.6: icmp_seq=6 ttl=64 time=1.820 ms
64 bytes from 192.168.2.6: icmp_seq=7 ttl=64 time=1.835 ms
64 bytes from 192.168.2.6: icmp_seq=8 ttl=64 time=1.789 ms
64 bytes from 192.168.2.6: icmp_seq=9 ttl=64 time=1.844 ms

--- drake.network.dev ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.726/1.812/1.910/0.053 ms

The access point I am using is the Unifi AC AP LITE and it is connected directly to my pfSense box which I used to record all the ping data for these tests to keep things mostly consistent. I am at a complete loss as to what could be causing these issues and would appreciate any help in solving them.

Usually with ping times it has to deal with location, or what channel the AP is operating on. Do you have overlapping channels? Is the AP in a good location relevant to where you are testing? We need some more info to trouble shoot properly.

EDIT:

Thank you for including the AP you are using,

But the IP address do need more of an explanation. Is that the subnet of you main gateway, or is that the IP of the AP itself. Because we would need to conduct pings test directly to the AP instead of going through the AP to the gateway.

Also, i notice that you are using 5 GHz, but keep in mind that 5 GHz is not always the best option for coverage. There are situations where 2.4 GHz is better.

Agree with Dynamic_Gravity, maybe tell us what kind of brand and model (modem/router) you are using for the connection

I used WiFi Analyser on my phone and I can't see any overlapping channels (In fact I can only see my access point and nothing else), also the access point is downstairs and is pretty much directly below all the devices I tested apart from my mothers computer.

I conducted the test from my pfSense box which is connected to the AP through Ethernet but I get similar results if I SSH into the access point and run a ping directly from it:

PING 192.168.2.5 (192.168.2.5): 56 data bytes
64 bytes from 192.168.2.5: seq=0 ttl=64 time=1.570 ms
64 bytes from 192.168.2.5: seq=1 ttl=64 time=26.886 ms
64 bytes from 192.168.2.5: seq=2 ttl=64 time=47.338 ms
64 bytes from 192.168.2.5: seq=3 ttl=64 time=71.187 ms
64 bytes from 192.168.2.5: seq=4 ttl=64 time=69.331 ms
64 bytes from 192.168.2.5: seq=5 ttl=64 time=22.298 ms
64 bytes from 192.168.2.5: seq=6 ttl=64 time=0.685 ms
64 bytes from 192.168.2.5: seq=7 ttl=64 time=67.783 ms
64 bytes from 192.168.2.5: seq=8 ttl=64 time=67.713 ms
--- 192.168.2.5 ping statistics ---
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 0.685/41.643/71.187 ms

Changing from 5GHz to 2.4GHz doesn't seem to make any difference as the pings are still just as high.

PING 192.168.2.5 (192.168.2.5): 56 data bytes
64 bytes from 192.168.2.5: seq=0 ttl=64 time=1.614 ms
64 bytes from 192.168.2.5: seq=1 ttl=64 time=371.834 ms
64 bytes from 192.168.2.5: seq=2 ttl=64 time=292.389 ms
64 bytes from 192.168.2.5: seq=3 ttl=64 time=100.356 ms
64 bytes from 192.168.2.5: seq=4 ttl=64 time=1.502 ms
64 bytes from 192.168.2.5: seq=5 ttl=64 time=1.601 ms
64 bytes from 192.168.2.5: seq=6 ttl=64 time=1.549 ms
--- 192.168.2.5 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 1.502/110.120/371.834 ms

Thanks for replying with more info. Really helps!

trying pinging the device from a client to the AP with these parameters:

ping -f -n 100 192.168.2.5

this will send 100 packets, and turns on the DO NOT FRAGMENT flag. Post results below.

EDIT: Had the incorrect number flag (fixed)

All I get when I run the command is this: connect: Network is unreachable

how are you pinging?

You should just be able to type that in terminal.

hmm, I suspect the command may be wrong as I think it is attempting to connect to 100 and not 192.168.2.5 because if I remove the 100 I get this:

PING 192.168.2.5 (192.168.2.5) 56(84) bytes of data.
.^C
--- 192.168.2.5 ping statistics ---
1881 packets transmitted, 1880 received, 0% packet loss, time 6424ms
rtt min/avg/max/mdev = 1.528/3.276/10.252/0.775 ms, ipg/ewma 3.417/3.128 ms

it was a windows terminal command. I copy pasted the command (changed to ip address of course), and it worked as expected.

BTW, those speeds look to be what they should be.

ah, I am running Linux so that may be why.

yeah in linux it would be

ping -f -c 100 192.168.2.5

So it looked like fragmentation was our problem. But im still waiting to see your new results.

I get this:

PING 192.168.2.5 (192.168.2.5) 56(84) bytes of data.
 
--- 192.168.2.5 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 340ms
rtt min/avg/max/mdev = 1.728/3.317/6.416/0.826 ms, ipg/ewma 3.442/3.624 ms
1 Like

Yup you're issue is due to fragmentation; if you have kept the rest of your results as controlled as possible to your original testing.

Fix: try enabling jumbo packet frames in your routers settings.

Should be already using jumbo frames as the MTU for my WiFi interface is set to 9000.

If its not already enabled it, then try it out. However, even though your MTU is set for that for wireless devices, when you send data from the AP to the router, it has to set the MTU back down to 1500 Bytes because it is traveling through an Ethernet uplink. So if jumbo frames are not already enabled, then enable them and see if that helps. If they are already enabled, then try turning them off and forcing a default MTU of 1500.

The MTU on my router side is at 9000 so I am amusing that is for Ethernet link and the AP is still set to 1500