Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)

[stevestrong]

Thanks for the feedback.

However, I don't think that this is related to un-ACKed frames.
The reason (beside that I increased the Rx buffer from 4 to 8):

The GIF file in question (from the capture) has 2615 bytes.
The file is requested in frame 184.
STM32 send PSH+ACK with 1460 bytes in frame 189 (0.6 ms after request).
The client (PC) send ACK to that in frame 225 (~41ms after the previous
frame, due to another file is sent in between).

And now the issue: the rest of GIF data (1155 bytes) is sent in next frame
226, which is ~1.9 second later!

IMHO, all the ACK packets are received from client.

As frame 224 (being an ACK to a previous FIN+ACK) is transmitted from STM32,
and the next frame 225 comes only after ~41 ms, I think there is enough time
for LwIP to do house keeping and have an empty buffer and time and resources
to respond a.s.a.p. But obviously something hinders LwIP to do that.

Can you maybe point out which part of LwIP should I monitor to get this
resolved?



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html