High ping for upload from wifi-router to some devices

[reza]

I have noticed that I have upload ping from openwrt router wifi to some of my devices.
I dont know if this is recent or not but I am asking here to see if this is fixable.

when I ping from wifi-router to my laptop I get ping usually under 5ms and mostly 1-2-3 ms .
but when I do to my android phone and tablet I get higher than 150 and many higher than 200ms.
this is regardless of distance to router.

upload from device to router is also higher but not that drastic.
from my phone and tablet is 18ms.
both of those are android and my laptop is linux.

is this normal?

I know that at day my laptop also has issues with wifi ssh (seems slow but I didnt investigate the ping that time but will try later)
but I did this test at night.

openwrt version is 21.02

but after some time that upload ping goes down like so

64 bytes from 192.168.1.13: icmp_seq=150 ttl=64 time=1.47 ms
64 bytes from 192.168.1.13: icmp_seq=151 ttl=64 time=41.8 ms
64 bytes from 192.168.1.13: icmp_seq=152 ttl=64 time=172 ms
64 bytes from 192.168.1.13: icmp_seq=153 ttl=64 time=194 ms
64 bytes from 192.168.1.13: icmp_seq=154 ttl=64 time=115 ms
64 bytes from 192.168.1.13: icmp_seq=155 ttl=64 time=139 ms
64 bytes from 192.168.1.13: icmp_seq=156 ttl=64 time=2.28 ms
64 bytes from 192.168.1.13: icmp_seq=157 ttl=64 time=83.1 ms
64 bytes from 192.168.1.13: icmp_seq=158 ttl=64 time=2.20 ms
64 bytes from 192.168.1.13: icmp_seq=159 ttl=64 time=1.06 ms
64 bytes from 192.168.1.13: icmp_seq=160 ttl=64 time=152 ms
64 bytes from 192.168.1.13: icmp_seq=161 ttl=64 time=173 ms
64 bytes from 192.168.1.13: icmp_seq=162 ttl=64 time=196 ms
64 bytes from 192.168.1.13: icmp_seq=163 ttl=64 time=118 ms
64 bytes from 192.168.1.13: icmp_seq=164 ttl=64 time=141 ms
64 bytes from 192.168.1.13: icmp_seq=165 ttl=64 time=163 ms
64 bytes from 192.168.1.13: icmp_seq=166 ttl=64 time=1.61 ms
64 bytes from 192.168.1.13: icmp_seq=167 ttl=64 time=1.85 ms
64 bytes from 192.168.1.13: icmp_seq=168 ttl=64 time=1.59 ms
64 bytes from 192.168.1.13: icmp_seq=169 ttl=64 time=1.81 ms
64 bytes from 192.168.1.13: icmp_seq=170 ttl=64 time=12.2 ms
64 bytes from 192.168.1.13: icmp_seq=171 ttl=64 time=1.89 ms
64 bytes from 192.168.1.13: icmp_seq=172 ttl=64 time=1.91 ms
64 bytes from 192.168.1.13: icmp_seq=173 ttl=64 time=2.51 ms
64 bytes from 192.168.1.13: icmp_seq=174 ttl=64 time=3.54 ms
64 bytes from 192.168.1.13: icmp_seq=175 ttl=64 time=0.783 ms
64 bytes from 192.168.1.13: icmp_seq=176 ttl=64 time=2.40 ms
64 bytes from 192.168.1.13: icmp_seq=177 ttl=64 time=3.80 ms

though this result is not the usual one and usually more of them are high.

like so

OpenWrt# ping 192.168.1.13
PING 192.168.1.13 (192.168.1.13) 56(84) bytes of data.
64 bytes from 192.168.1.13: icmp_seq=1 ttl=64 time=127 ms
64 bytes from 192.168.1.13: icmp_seq=2 ttl=64 time=152 ms
64 bytes from 192.168.1.13: icmp_seq=3 ttl=64 time=176 ms
64 bytes from 192.168.1.13: icmp_seq=4 ttl=64 time=200 ms
64 bytes from 192.168.1.13: icmp_seq=5 ttl=64 time=223 ms
64 bytes from 192.168.1.13: icmp_seq=6 ttl=64 time=141 ms
64 bytes from 192.168.1.13: icmp_seq=7 ttl=64 time=167 ms
64 bytes from 192.168.1.13: icmp_seq=8 ttl=64 time=189 ms
64 bytes from 192.168.1.13: icmp_seq=9 ttl=64 time=213 ms
64 bytes from 192.168.1.13: icmp_seq=10 ttl=64 time=134 ms
64 bytes from 192.168.1.13: icmp_seq=11 ttl=64 time=157 ms
64 bytes from 192.168.1.13: icmp_seq=12 ttl=64 time=178 ms
64 bytes from 192.168.1.13: icmp_seq=13 ttl=64 time=203 ms
64 bytes from 192.168.1.13: icmp_seq=14 ttl=64 time=125 ms
64 bytes from 192.168.1.13: icmp_seq=15 ttl=64 time=148 ms
64 bytes from 192.168.1.13: icmp_seq=16 ttl=64 time=170 ms
64 bytes from 192.168.1.13: icmp_seq=17 ttl=64 time=193 ms
64 bytes from 192.168.1.13: icmp_seq=18 ttl=64 time=217 ms
64 bytes from 192.168.1.13: icmp_seq=19 ttl=64 time=139 ms
64 bytes from 192.168.1.13: icmp_seq=20 ttl=64 time=2.44 ms
64 bytes from 192.168.1.13: icmp_seq=21 ttl=64 time=184 ms
64 bytes from 192.168.1.13: icmp_seq=22 ttl=64 time=207 ms
64 bytes from 192.168.1.13: icmp_seq=23 ttl=64 time=129 ms
64 bytes from 192.168.1.13: icmp_seq=24 ttl=64 time=153 ms
64 bytes from 192.168.1.13: icmp_seq=25 ttl=64 time=176 ms
64 bytes from 192.168.1.13: icmp_seq=26 ttl=64 time=198 ms
64 bytes from 192.168.1.13: icmp_seq=27 ttl=64 time=120 ms
64 bytes from 192.168.1.13: icmp_seq=28 ttl=64 time=142 ms
64 bytes from 192.168.1.13: icmp_seq=29 ttl=64 time=163 ms
64 bytes from 192.168.1.13: icmp_seq=30 ttl=64 time=188 ms
64 bytes from 192.168.1.13: icmp_seq=31 ttl=64 time=213 ms
64 bytes from 192.168.1.13: icmp_seq=32 ttl=64 time=133 ms
64 bytes from 192.168.1.13: icmp_seq=33 ttl=64 time=156 ms
64 bytes from 192.168.1.13: icmp_seq=34 ttl=64 time=179 ms
64 bytes from 192.168.1.13: icmp_seq=35 ttl=64 time=204 ms
64 bytes from 192.168.1.13: icmp_seq=36 ttl=64 time=124 ms
64 bytes from 192.168.1.13: icmp_seq=37 ttl=64 time=147 ms
64 bytes from 192.168.1.13: icmp_seq=38 ttl=64 time=170 ms
64 bytes from 192.168.1.13: icmp_seq=39 ttl=64 time=192 ms
64 bytes from 192.168.1.13: icmp_seq=40 ttl=64 time=217 ms
64 bytes from 192.168.1.13: icmp_seq=41 ttl=64 time=137 ms
64 bytes from 192.168.1.13: icmp_seq=42 ttl=64 time=162 ms
^C
--- 192.168.1.13 ping statistics ---
42 packets transmitted, 42 received, 0% packet loss, time 41069ms
rtt min/avg/max/mdev = 2.439/165.414/222.663/39.040 ms

also ping from my laptop to the tablet (which has better wifi reception than my phone) is also high like so

laptop% ping 192.168.1.13
PING 192.168.1.13 (192.168.1.13) 56(84) bytes of data.
64 bytes from 192.168.1.13: icmp_seq=1 ttl=64 time=61.7 ms
64 bytes from 192.168.1.13: icmp_seq=2 ttl=64 time=375 ms
64 bytes from 192.168.1.13: icmp_seq=3 ttl=64 time=346 ms
64 bytes from 192.168.1.13: icmp_seq=4 ttl=64 time=228 ms
64 bytes from 192.168.1.13: icmp_seq=5 ttl=64 time=261 ms
64 bytes from 192.168.1.13: icmp_seq=6 ttl=64 time=451 ms
64 bytes from 192.168.1.13: icmp_seq=7 ttl=64 time=391 ms
64 bytes from 192.168.1.13: icmp_seq=8 ttl=64 time=218 ms
64 bytes from 192.168.1.13: icmp_seq=9 ttl=64 time=140 ms
64 bytes from 192.168.1.13: icmp_seq=10 ttl=64 time=541 ms
64 bytes from 192.168.1.13: icmp_seq=11 ttl=64 time=182 ms
64 bytes from 192.168.1.13: icmp_seq=12 ttl=64 time=398 ms
64 bytes from 192.168.1.13: icmp_seq=13 ttl=64 time=127 ms
64 bytes from 192.168.1.13: icmp_seq=14 ttl=64 time=210 ms
64 bytes from 192.168.1.13: icmp_seq=15 ttl=64 time=275 ms
64 bytes from 192.168.1.13: icmp_seq=16 ttl=64 time=199 ms
64 bytes from 192.168.1.13: icmp_seq=17 ttl=64 time=396 ms
64 bytes from 192.168.1.13: icmp_seq=18 ttl=64 time=739 ms
64 bytes from 192.168.1.13: icmp_seq=19 ttl=64 time=325 ms
64 bytes from 192.168.1.13: icmp_seq=20 ttl=64 time=313 ms
64 bytes from 192.168.1.13: icmp_seq=21 ttl=64 time=202 ms
64 bytes from 192.168.1.13: icmp_seq=22 ttl=64 time=390 ms
64 bytes from 192.168.1.13: icmp_seq=23 ttl=64 time=373 ms
64 bytes from 192.168.1.13: icmp_seq=24 ttl=64 time=465 ms
64 bytes from 192.168.1.13: icmp_seq=25 ttl=64 time=194 ms
64 bytes from 192.168.1.13: icmp_seq=26 ttl=64 time=304 ms
64 bytes from 192.168.1.13: icmp_seq=27 ttl=64 time=34.2 ms
64 bytes from 192.168.1.13: icmp_seq=28 ttl=64 time=556 ms
64 bytes from 192.168.1.13: icmp_seq=29 ttl=64 time=219 ms
64 bytes from 192.168.1.13: icmp_seq=30 ttl=64 time=204 ms
64 bytes from 192.168.1.13: icmp_seq=31 ttl=64 time=126 ms
64 bytes from 192.168.1.13: icmp_seq=32 ttl=64 time=647 ms
64 bytes from 192.168.1.13: icmp_seq=33 ttl=64 time=383 ms
64 bytes from 192.168.1.13: icmp_seq=34 ttl=64 time=422 ms
64 bytes from 192.168.1.13: icmp_seq=35 ttl=64 time=212 ms
64 bytes from 192.168.1.13: icmp_seq=36 ttl=64 time=501 ms
64 bytes from 192.168.1.13: icmp_seq=37 ttl=64 time=218 ms
64 bytes from 192.168.1.13: icmp_seq=38 ttl=64 time=180 ms
64 bytes from 192.168.1.13: icmp_seq=39 ttl=64 time=206 ms
64 bytes from 192.168.1.13: icmp_seq=40 ttl=64 time=124 ms
64 bytes from 192.168.1.13: icmp_seq=41 ttl=64 time=144 ms
64 bytes from 192.168.1.13: icmp_seq=42 ttl=64 time=171 ms
64 bytes from 192.168.1.13: icmp_seq=43 ttl=64 time=691 ms
64 bytes from 192.168.1.13: icmp_seq=44 ttl=64 time=216 ms
64 bytes from 192.168.1.13: icmp_seq=45 ttl=64 time=468 ms
64 bytes from 192.168.1.13: icmp_seq=46 ttl=64 time=247 ms
64 bytes from 192.168.1.13: icmp_seq=47 ttl=64 time=233 ms
64 bytes from 192.168.1.13: icmp_seq=48 ttl=64 time=296 ms
64 bytes from 192.168.1.13: icmp_seq=49 ttl=64 time=408 ms
64 bytes from 192.168.1.13: icmp_seq=50 ttl=64 time=214 ms
64 bytes from 192.168.1.13: icmp_seq=51 ttl=64 time=240 ms
64 bytes from 192.168.1.13: icmp_seq=52 ttl=64 time=346 ms
64 bytes from 192.168.1.13: icmp_seq=53 ttl=64 time=355 ms
64 bytes from 192.168.1.13: icmp_seq=54 ttl=64 time=160 ms
64 bytes from 192.168.1.13: icmp_seq=55 ttl=64 time=350 ms
64 bytes from 192.168.1.13: icmp_seq=56 ttl=64 time=179 ms
64 bytes from 192.168.1.13: icmp_seq=57 ttl=64 time=240 ms
64 bytes from 192.168.1.13: icmp_seq=58 ttl=64 time=228 ms
64 bytes from 192.168.1.13: icmp_seq=59 ttl=64 time=82.8 ms
64 bytes from 192.168.1.13: icmp_seq=60 ttl=64 time=169 ms
64 bytes from 192.168.1.13: icmp_seq=61 ttl=64 time=189 ms
64 bytes from 192.168.1.13: icmp_seq=62 ttl=64 time=211 ms
64 bytes from 192.168.1.13: icmp_seq=63 ttl=64 time=136 ms
64 bytes from 192.168.1.13: icmp_seq=64 ttl=64 time=157 ms
64 bytes from 192.168.1.13: icmp_seq=65 ttl=64 time=218 ms
^C
--- 192.168.1.13 ping statistics ---
65 packets transmitted, 65 received, 0% packet loss, time 64084ms
rtt min/avg/max/mdev = 34.246/284.422/738.748/146.519 ms

[psherman]

This is not uncommon for wireless battery powered devices like phones and tablets. They tend to power down the radio and wake it periodically to save power - this can be in the range of 10s-100s of milliseconds of sleep, short enough to have the illusion (at human scale) of being online all the time, but it does have tangible benefits in terms of battery life.

The more important question is if those devices have issues with bandwidth when if comes to transferring data or any significant issues with latency when it comes to streaming applications (games, videos/audio, etc).

[reza]

if it is this then why when I am using the device I still get this ping?

and why not the download ping (from device to router) and only upload ping?

also I noticed that my ssh mounted drive (on linux from a lan connected device on router lan) also feels very slow.
this happened after my upgrade to openwr21.02 but because I was setting the openwrt from scratch I didnt notice this at first.

now I remember that the ssh issue appeared after update to openwrt 21.02

[psherman]

@reza

if it is this then why when I am using the device I still get this ping?

Even if you are using the device, the wifi radio(s) may be placed into sleep mode to save power. This segment of the OS X Mavericks keynote describes this concept around processor utilization, but it applies to the radios, too.

When you are pinging from device > router, the ping app is most likely keeping the wifi chip up at full power mode for maximum responsiveness. When the ping is reversed (router > device), the same is not likely true in terms of the radio being kept at full power mode.

@reza

this happened after my upgrade to openwr21.02 but because I was setting the openwrt from scratch I didnt notice this at first.

It is certainly possible that there is something different in the way that 21.02 is behaving, but to be sure, you would probably need to run a test either with a totally default 21.02 (just reset to defaults and do the absolute minimum setup to enable wifi) or test with 19.07 (or whatever you were using previously). Do not preserve settings if you downgrade -- this will almost certainly cause issues. If you take a backup of your current config, you can restore easily.

@reza

now I remember that the ssh issue appeared after update to openwrt 21.02

If your devices happened to also get updates around the same time, it could be improvements n the power efficiency of the OS. If not, then the above idea of a default config and/or previous OpenWrt version would answer this more completely.

@reza

also I noticed that my ssh mounted drive (on linux from a lan connected device on router lan) also feels very slow.

Same deal here -- run bandwidth tests with the shared drive using your current config on 21.02, a default 21.02 config, and your previous version.

[psherman]

And just to prove that this is the case...

I pinged from my Mac Pro to my iPhone and got the following results:

Notice that the min/average/max/stddev indicates that the response is anything but consistent.

By contrast, my iPhone pinging my Mac Pro has much faster and more consistent results:

And my WiFi is actually a very well tuned unifi setup which performs really well across all of my WiFi based devices.

[reza]

so I shouldnt be worried? and it is normal?
what about the value of the ping? isnt too high even for what you described?
your phone gets average ~50ms, mine gets 200ms?
is this android vs ios? or build quality of phone wifi part?

today I tested with another android phone and saw something weirder.
I can ping the openwrt, but when I ping from openwrt to phone it got no ping.
then it got some ping but then no ping.

like this:

ping poco
PING poco.lan (192.168.1.16) 56(84) bytes of data.
64 bytes from poco.lan (192.168.1.16): icmp_seq=17 ttl=64 time=108 ms
64 bytes from poco.lan (192.168.1.16): icmp_seq=18 ttl=64 time=6.72 ms
64 bytes from poco.lan (192.168.1.16): icmp_seq=19 ttl=64 time=154 ms
64 bytes from poco.lan (192.168.1.16): icmp_seq=20 ttl=64 time=178 ms
64 bytes from poco.lan (192.168.1.16): icmp_seq=21 ttl=64 time=204 ms
64 bytes from poco.lan (192.168.1.16): icmp_seq=46 ttl=64 time=175 ms
64 bytes from poco.lan (192.168.1.16): icmp_seq=47 ttl=64 time=200 ms
64 bytes from poco.lan (192.168.1.16): icmp_seq=48 ttl=64 time=120 ms
64 bytes from poco.lan (192.168.1.16): icmp_seq=49 ttl=64 time=142 ms
64 bytes from poco.lan (192.168.1.16): icmp_seq=50 ttl=64 time=167 ms
^C
--- poco.lan ping statistics ---
51 packets transmitted, 10 received, 80.3922% packet loss, time 50557ms
rtt min/avg/max/mdev = 6.720/145.419/203.549/54.805 ms

what can cause this?

I have some similar issues with when I had two wifi ap configured on the 5gz on openwrt, one for wpa2 and one for wpa3.
I got a lot of issues with devices not seeing each other.
when I removed the wpa3 they saw each other.

but now this?
is this something normal or too weird?
phone is near the openwrt and has great wifi signal and can ping openwrt and internet but other devices ping it have this issue.

can firewall be the issue here?
can I disable firefox as in have all the packages accepted and firewall not matter?

I really cant test with a 19.07 because I dont have easy lan access to openwrt device but reconfiguring it last time was a pain in the ass.

[psherman]

@reza - my point, and my followup with the ping results from my devices, was that you shouldn't worry about the ping times with a destination of mobile devices (and even things like smart thermostats) because they are almost certainly powering down the radios to improve battery life. The exact numbers for the pings, within reason, are not really important, provided that the mobile device gets reasonable results when initiated by a local app (as compared to a response from an external ping).

With respect to the other device showing high packet loss -- again, same deal. It may be powering the radio down for longer periods and missing the pings entirely.

Local firewall rules (i.e. on the devices themselves) can also impact the visibility on the network with pings and/or other methods.

Since you have said that you don't want to try flashing down to 19.07 to run experiments, you'll just have to take it on faith that these issues are almost certainly related to the things I have described, and probably not related to the version of OpenWrt that you are using.

The important thing to be monitoring is the network performance (latency and bandwidth) of the devices in question with respect to local usage (web, games, video/audio streaming, etc.). If those are not problematic, then there really is nothing to worry about with the high latency and/or dropped packets on your mobile devices.