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

[address@hidden]

Am 28.12.2018 um 22:17 schrieb stevestrong:
> Thanks for the feedback.
>
> However, I don't think that this is related to un-ACKed frames.

I did not only have lost ACKs but also some delayed RX packets. So it 
could well still be the driver delivering packets too late to lwIP.

> 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.

I cannot follow this number (nor the other numbers you mention below) in 
the pcap you mentioned in the OP.

Anyway, have you checked lwip_stats? Check for 'err' being != 0.

Regards,
Simon

> 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