|
From: | Dave Nadler |
Subject: | Re: [lwip-users] Throughput benchmark question - nasty ~1.5 second pauses |
Date: | Sun, 5 May 2019 09:47:08 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
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) */ tcp_rexmit_fast(pcb); } 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?
The client picks up and continues happily regardless and I get the desired through-put with no problematic long pauses... Thanks!
Best Regards, Dave On 3/15/2019 5:56 PM, Dave Nadler
wrote:
To recap: LwIP 2.1.2 on FreeRTOS 9, ST32F429, IPv4, TCP.
-- Dave Nadler, USA East Coast voice (978) 263-0097, address@hidden, Skype Dave.Nadler1 |
[Prev in Thread] | Current Thread | [Next in Thread] |