Have you seen delays to ACK TCP packets?

[DavidVentura]

Hi!
I've been building a snapclient for the esp32 as well (here) and I've been getting "dropouts" seemingly every 70 minutes.
The way that I observe these "dropouts" is that the ESP32 will not ACK a packet, causing a retransmission on the snapserver, which delays the next WireChunk by 600ms; sadly, 600ms is larger than my current buffer 😢 and this causes a gap in playback

My question is, have you experienced similar behavior? I've been poking around your sdkconfig file and checking for any possible tunable; I've moved WIFI and IP code to IRAM, increased the TCP and WIFI RX mboxes, etc.

[CarlosDerSeher]

No dropouts here. 600ms seems like a very long time to me and I don't think this is a TCP problem. Did you rule out your access point / internet / server as the source of error?

[DavidVentura]

Well, I don't know if it's my access point.
I have a packet capture which shows that the ACK was received 571ms after the initial packet:

I'm fishing a bit at this point, as I'm out of leads with my implementation.

Have you tested your implementation of snapclient with a 500ms (or smaller) buffer for extended periods of time? (>1h)

[CarlosDerSeher]

I actually set it to 500ms recently but I am not at home much so I didn't use snapclient very often. I see if I can try this weekend. Normally I use it with >700ms. What you can try, is to print rssi and your buffer status to the log so you can see when it is happening.

Do you have any other traffic on your esp32? From your Readme I am guessing you are using ntp for synchronization? Maybe your problem lies there? Try to disable it to see if things work out then...

[CarlosDerSeher]

@DavidVentura did you resolve your issue? Are you using sntp for syncing in some way? I don't have any dropouts in my network even if just using 500ms buffers.