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
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users