High performance UDP cast problem

[robiwan]

I have a setup where I post UDP multicast packages from a RPi, then the AP does multicast-to-unicast and sends to clients (ESP32-S3). The RPi sends a packet each 2666 us (stably), but the ESP32 struggles to keep up. I'm using the udp_multicast server ESP-IDF example (IPv4). No other traffic on the AP, it is dedicated for this purpose only.

An excerpt of logging, where the next to last value is the difference in microseconds from the previous packet (for each packet, and note that the logging is done to an array so no logging occurs during actual reception, but only afterwards):
...
I (455353) multicast: 62: 63, 2667, 7228 (544)
I (455358) multicast: 63: 64, 2665, 4832 (544)
I (455363) multicast: 64: 65, 2666, 5127 (544)
I (455368) multicast: 65: 66, 2667, 7167 (544)
I (455373) multicast: 66: 67, 2665, 4913 (544)
I (455378) multicast: 67: 68, 2666, 5232 (544)
I (455384) multicast: 68: 69, 2667, 5086 (544)
I (455389) multicast: 69: 70, 2665, 7100 (544)
I (455394) multicast: 70: 71, 2666, 4944 (544)
I (455399) multicast: 71: 72, 2667, 5172 (544)
I (455404) multicast: 72: 73, 2665, 5126 (544)
I (455409) multicast: 73: 74, 2666, 7102 (544)
I (455414) multicast: 74: 75, 2667, 4990 (544)
...
As seen, the time is nowhere near 2666 us (+/- jitter) which is what I'd expect. I've set the FreeRTOS frequency to 1000 Hz, but yeah, that didn't help.

I'd imagine that the ISR for the WiFi interface should be fairly on the dot wrt to timing, so where is the latency introduced?

[robiwan]

Running tshark on the RPi5 I can see that the packets are timely delivered:

rpi@rpi5:~ $ sudo tshark -i wlan0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlan0'
** (tshark:3893) 16:33:27.684476 [Main MESSAGE] -- Capture started.
** (tshark:3893) 16:33:27.684549 [Main MESSAGE] -- File: "/tmp/wireshark_wlan0EFWBY2.pcapng"
1 0.000000000 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64
2 0.002653500 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64
3 0.005318816 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64
4 0.007983872 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64
5 0.010649576 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64
6 0.013315780 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64
7 0.015981854 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64
8 0.018647651 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64
9 0.021317559 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64
10 0.023980763 192.168.4.1 → 232.10.11.12 UDP 106 35549 → 3333 Len=64

Packet interval is very close to expected 2666 us. So the problem must lie on the ESP32 side.