[Top][All Lists]

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

[lwip-users] R: problem after a packet loss event

From: Fabrizio Beltrandi
Subject: [lwip-users] R: problem after a packet loss event
Date: Tue, 12 May 2015 00:43:29 +0200

when I receive data in my receive callback I only copy packet data in
another buffer with DMA, then I think that my firmware application doesn't
take more time than expected one. In my main instead I have a loop while
where at the maximum speed I perform a call at xemacif_input() function
continuosly. I don't know why, after packet loss, my app needs about
120 ms to get every packet. I think that during packet loss recovery happens
something that disrupt synchronism, but I don't know if this is in my app or
in lwip stack. Hardware should be ok because I am working with microZed and
carrier board that are Xilinx reference boards. Tomorrow I'll try to augment
memory parameters in LwIP, and I'll disable all possible other pieces of
software don't relevant in reception of data. Further I'll try to trace
timing and duration of receive callback and xemacif_input() calls with aid 
of hardware signal flag and oscilloscope.
I'll tell you results

-----Messaggio originale-----
Da: address@hidden
[mailto:address@hidden Per conto di Sergio
R. Caprile
Inviato: lunedì 11 maggio 2015 15.12
A: address@hidden
Oggetto: Re: [lwip-users] problem after a packet loss event

My 2 cents:

frame 644 gets lost
frame 651 says "send 624651"
frame 652 repeats, why ? possible software problem here, short timeout ?
frame 653 is the retransmission
frame 654 ACKs it for good
frame 655 says "send 624651" which in this context means "resume sending
after frame 650". Your device buffered content in 645+647+648+650 = 4 x

There is a 125ms delay between 654 and 655. Looks like something went
out of sync inside your device. What are you exactly doing with that
much data you are receiving ? Is it possible that you store it somewhere
and that somewhere takes more than expected and a timer times out and
then is improperly reset and immediately times out again and the system
goes nuts ?
Why did 644 get lost ? This is between your PC -> your device. Hardware
? Driver ? Looks like a driver not attend in due time problem.
My best guess on the window is that lwIP reduces its size based on the
ACK delay between frames 650 and 655, which is the time it took for your
app to tell the stack to resume sending.
I can't guess why the PC doesn't fill that window, that depends on the
app in your PC afaik, but I can tell you that 2352 is not a multiple of
TCP_MSS, so only 1 fits in there. Nagle ?

Good report, btw


lwip-users mailing list

reply via email to

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