Strange 'sawtooth' pattern ICMP latency measurements

[clarkmcc]

trafficstars

Disclaimer: I'm new to embedded

I'm running the WiFi example with my esp32c6 with a few changes (like mem::forget the wifi type to keep it running beyond main), and I pinged it from my laptop for a couple hours. I've tested and seen the same behavior on an XIAO ESP32-C6 and a ESP32-C6 WROOM I saw this 'sawtooth' pattern consistently basically the entire time.

What's interesting is that I'm seeing latency as short as 2ms but it's consistently very short and very long in a saw pattern (my laptop, the esp32c6 and the wifi AP are all within 2ft of each other). Is there an explanation for this behavior?

10641 packets transmitted, 10639 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.784/179.418/885.236/100.006 ms

The following image illustrates the saw pattern even more by plotting the latency (X) against the previous ICMP request's latency (Y).

[clarkmcc]

As a point of reference, same laptop, same network, different target devices (instead of the ESP). None of these have the same reproducible pattern that the ESP has. Curious if that has anything to do with the networking implementation here.

A printer

Cell phone

Hardwired desktop

[ivmarkov]

No idea, but to remove the Rust ESP IDF wrappers out of the equation, can you try with some of the C wifi examples and see if you still get this behavior? If so, I guess you need to re-open the same issue in the ESP IDF repo...

[jothan]

Try calling this function somewhere early in your Wi-Fi init:

use esp_idf_svc::sys::{self, EspError};

pub fn wifi_disable_powersave() -> Result<(), EspError> {
    esp!(unsafe { sys::esp_wifi_set_ps(sys::wifi_ps_type_t_WIFI_PS_NONE) })
}

It should make a big difference, especially if you have a high DTIM on your network.