High variation in ping duartion

Hi,
I am using Toradex OS 7.1.0 on a verdin-imx8mm board.

The ping duration to my default gateway has a high variation:
64 bytes from 192.168.2.1: seq=181 ttl=64 time=5.394 ms
64 bytes from 192.168.2.1: seq=182 ttl=64 time=5.954 ms
64 bytes from 192.168.2.1: seq=183 ttl=64 time=6.503 ms
64 bytes from 192.168.2.1: seq=184 ttl=64 time=5.080 ms
64 bytes from 192.168.2.1: seq=185 ttl=64 time=6.026 ms
64 bytes from 192.168.2.1: seq=186 ttl=64 time=105.493 ms
64 bytes from 192.168.2.1: seq=187 ttl=64 time=9.639 ms
64 bytes from 192.168.2.1: seq=188 ttl=64 time=6.041 ms
64 bytes from 192.168.2.1: seq=189 ttl=64 time=9.433 ms
64 bytes from 192.168.2.1: seq=190 ttl=64 time=78.120 ms
64 bytes from 192.168.2.1: seq=191 ttl=64 time=3.168 ms
64 bytes from 192.168.2.1: seq=192 ttl=64 time=6.044 ms
64 bytes from 192.168.2.1: seq=193 ttl=64 time=46.036 ms
64 bytes from 192.168.2.1: seq=194 ttl=64 time=69.574 ms
64 bytes from 192.168.2.1: seq=195 ttl=64 time=4.872 ms
64 bytes from 192.168.2.1: seq=196 ttl=64 time=4.975 ms
64 bytes from 192.168.2.1: seq=197 ttl=64 time=6.158 ms
64 bytes from 192.168.2.1: seq=198 ttl=64 time=5.943 ms
64 bytes from 192.168.2.1: seq=199 ttl=64 time=85.926 ms
64 bytes from 192.168.2.1: seq=200 ttl=64 time=109.721 ms
64 bytes from 192.168.2.1: seq=201 ttl=64 time=30.509 ms
64 bytes from 192.168.2.1: seq=202 ttl=64 time=7.463 ms
64 bytes from 192.168.2.1: seq=203 ttl=64 time=2.431 ms
64 bytes from 192.168.2.1: seq=204 ttl=64 time=5.693 ms
64 bytes from 192.168.2.1: seq=205 ttl=64 time=5.440 ms
64 bytes from 192.168.2.1: seq=206 ttl=64 time=1.231 ms
64 bytes from 192.168.2.1: seq=207 ttl=64 time=70.773 ms
64 bytes from 192.168.2.1: seq=208 ttl=64 time=6.063 ms
64 bytes from 192.168.2.1: seq=209 ttl=64 time=118.506 ms
64 bytes from 192.168.2.1: seq=210 ttl=64 time=6.058 ms
64 bytes from 192.168.2.1: seq=211 ttl=64 time=6.064 ms
64 bytes from 192.168.2.1: seq=212 ttl=64 time=6.003 ms

sometimes I see pings above 1000ms!

The connection looks stable, signal strength looks ok:

The board is not running any software apart of the OS, CPU load is about 1%.
Running the CPU @ 100% (with an empty while loop) - has no effect to the ping variations.
My Laptop host, just next to the board has a stable ping of 3ms (also WiFi).

Do you have an idea why the connection is behaving like this?

Thanks for you answers!
Cheers,
Chris

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello! It sounds like you’re experiencing some WiFi connectivity issues with your Toradex device. Let’s explore a few areas that might help resolve this:

  1. Power Management Settings:

    • Check if power-saving modes are affecting your WiFi module. You can verify and adjust these settings using NetworkManager. Look for the powersave setting in your NetworkManager configuration file; a value of powersave=2 indicates that power saving is disabled.
  2. Signal Interference:

    • Even if your signal strength appears strong, it’s worth checking for potential sources of interference between your router and device. This could include other electronic devices or physical obstructions.
  3. Network Configuration:

    • Ensure your WiFi network settings are correctly configured. Make sure NetworkManager is set to automatically reconnect if the connection drops.
  4. Logs and Diagnostics:

    • Review system logs using dmesg or journalctl to identify any WiFi-related errors. Pay special attention to entries related to changes in the WiFi interface state.

These steps should help you diagnose and potentially resolve the connectivity issues. If you need further assistance, feel free to ask!

Best regards,
Toradex AI Assistant.

Please, also check if these links can help you solve your problem:

Wifi connection fails, Colibri iMX8X.

I like the idea with the power save function. But I can not find the NetworkManager config on my toradex image. It is not in /etc/Networkmanager. Where to put the powersave option?

Cheers,
Chris

Dear @chriz,

Thank you for sharing the issue you are experiencing. I have a rather trivial question which can happen from time to time: is it possible, that you are connected to the same network via both WiFi and Ethernet?

Should this not be the case or source of the latency I suspect that it might be due to either background scanning or the networkmanager scanning.
I saw that you shared excerpt from sequence number 181 onward. What did it look like before that?

Would you be able to share the output of nmcli with a command such as nmcli dev wifi list?
If the networks are mentioned twice in nmcli this suggests that the culprit is somewhere within that area.

Another possible issue could be that the networkmanager is still handling the uap interface. This should no longer be the case with your Torizon version, though this might still be worth checking.

Best regards,
Collin

Thanks for your reply- The toradex is connected over Wifi and Ethernet but separated in two different networks. Anyhow, I disconnected the Ethernet and connected only through wifi with the following ping response (starting at 0 :):
$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: seq=0 ttl=64 time=2.734 ms
64 bytes from 192.168.2.1: seq=1 ttl=64 time=2.443 ms
64 bytes from 192.168.2.1: seq=2 ttl=64 time=5.449 ms
64 bytes from 192.168.2.1: seq=3 ttl=64 time=6.074 ms
64 bytes from 192.168.2.1: seq=4 ttl=64 time=103.781 ms
64 bytes from 192.168.2.1: seq=5 ttl=64 time=8.295 ms
64 bytes from 192.168.2.1: seq=6 ttl=64 time=5.074 ms
64 bytes from 192.168.2.1: seq=7 ttl=64 time=1.824 ms
64 bytes from 192.168.2.1: seq=8 ttl=64 time=19.983 ms
64 bytes from 192.168.2.1: seq=9 ttl=64 time=2006.522 ms
64 bytes from 192.168.2.1: seq=10 ttl=64 time=1006.067 ms
64 bytes from 192.168.2.1: seq=11 ttl=64 time=5.622 ms
64 bytes from 192.168.2.1: seq=12 ttl=64 time=5.674 ms
64 bytes from 192.168.2.1: seq=13 ttl=64 time=1006.113 ms
64 bytes from 192.168.2.1: seq=14 ttl=64 time=5.687 ms
64 bytes from 192.168.2.1: seq=15 ttl=64 time=5.705 ms
64 bytes from 192.168.2.1: seq=16 ttl=64 time=5.736 ms
64 bytes from 192.168.2.1: seq=17 ttl=64 time=1005.546 ms
64 bytes from 192.168.2.1: seq=18 ttl=64 time=5.112 ms
64 bytes from 192.168.2.1: seq=19 ttl=64 time=1006.107 ms
64 bytes from 192.168.2.1: seq=20 ttl=64 time=5.694 ms
64 bytes from 192.168.2.1: seq=21 ttl=64 time=6.060 ms
64 bytes from 192.168.2.1: seq=22 ttl=64 time=5.318 ms
64 bytes from 192.168.2.1: seq=23 ttl=64 time=1009.426 ms
64 bytes from 192.168.2.1: seq=24 ttl=64 time=8.991 ms
64 bytes from 192.168.2.1: seq=25 ttl=64 time=7.490 ms
64 bytes from 192.168.2.1: seq=26 ttl=64 time=6.250 ms
64 bytes from 192.168.2.1: seq=27 ttl=64 time=6.726 ms
64 bytes from 192.168.2.1: seq=28 ttl=64 time=1006.033 ms
64 bytes from 192.168.2.1: seq=29 ttl=64 time=5.604 ms
64 bytes from 192.168.2.1: seq=30 ttl=64 time=6.611 ms
64 bytes from 192.168.2.1: seq=31 ttl=64 time=5.101 ms

here the output of the available networks. I am connected with “TEST_LAB_1”:

I disabled the 5G Network on the Router, there should only be one 2.4G Test lab SSID.

The UAP device is showing up when running nmcli:
uap0: unmanaged
“Marvell Wi-Fi”
wifi (mwifiex_sdio), 90:E8:68:6C:44:AF, hw, mtu 1500

Best Regards,
Chris

Dear @chriz,

This still looks like the reason for the latency might be network scanning. You might be able to disable it by setting the bssid parameter on the network profile. Via the following (untested) command you might be able to set it:
nmcli con mod <name_of_the_connection> 802-11-wireless.bssid "network_SSID"
The list of all parameters can be found here:
https://networkmanager.dev/docs/api/latest/settings-802-11-wireless.html
After setting the parameter you should be able to check it with the following command:
nmcli con show <name_of_the_connection>

May I ask what your inteded use of the wifi interface is?

Best regards,
Collin

Thanks for your responses. Meanwhile we figured it out, it was the power settings:
nmcli connection modify WIFI_SSID 802-11-wireless.powersave 2
did the trick.

Cheers,
Chris

Dear @chriz,

That’s great news! Thank you for sharing your solution!

Best regards,
Collin