[Top][All Lists]

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

Re: [lwip-users] Throughput benchmark question - nasty ~1.5 second pause

From: Dave Nadler
Subject: Re: [lwip-users] Throughput benchmark question - nasty ~1.5 second pauses
Date: Mon, 6 May 2019 17:22:59 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 5/6/2019 3:12 PM, address@hidden wrote:
Am 05.05.2019 um 15:47 schrieb Dave Nadler:
Hi all - Back to look at this delay issue. Update:
I studied the driver and ST-provided FreeRTOS/LwIP/cmsis glue and all
looks AOK,
unlike the extremely buggy code ST provides for ST32F7xx series.

Again, after a lost packet, the host (PC running Windows 10) issues a
_*single*_ duplicate-ack and waits.
LwIP receives the single duplicate ack and by design _*ignores it*_
(tcp_in.c lines 1207-1227).
LwIP takes two passes through slow_tmr (.5 sec intervals) before
retransmitting the lost packet.
Hence nasty >1 second delay.

I tried patching LwIP to _immediately_ retransmit on a duplicate ack
(line 1215):
               if (pcb->dupacks >= 1 /* DRN kludge prevents 1+sec delays
after lost packet, should be: 3 */) {
                 /* Do fast retransmit (checked via TF_INFR, not via
dupacks count) */
Wireshark shows a TCP out-of-order packet, which it did not do unpatched
(after the 1.5 sec delay):


Is this OK? Or is there something wrong in tcp_rexmit_fast?

No, fast_rexmit is supposed to kick in after 3 dupacks, not at the first

Thanks Simon, I can see that is the code's intent, except the PC never sends more than one dupack.
Sorry if I wasn't clear, my precise question is:
Why is tcp_rexmit_fast resulting in an out-of-order packet as reported by Wireshark?
Is something wrong in tcp_rexmit_fast?
Thanks again,
Best Regards, Dave

lwip-users mailing list

Dave Nadler, USA East Coast voice (978) 263-0097, address@hidden, Skype 

reply via email to

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