[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP

From: address@hidden
Subject: Re: [lwip-users] Randomly delayed frame (STM32070 package including LwIP v1.4.1)
Date: Fri, 28 Dec 2018 22:41:03 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3

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.


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

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

lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]