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 _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
