lwip-users
[Top][All Lists]
Advanced

[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: 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.
I want to see how much I can consistently push through the stack.
Made a simple test server (sockets API) which repeatedly outputs 101-character lines.
I access the server via PuTTY raw mode on Winbloze over a local network.
I can usually send 3 lines per msec for a second (3000 lines in 1 second), but...
Sometimes, I get ~ 1-second pauses (as seen in Putty or TeraTerm).

Here's the capture:

http://www.nadler.com/backups/20190227_Lwip_pause.pcapng

Everything is going swimmingly until 4316.

The windows client notes a missing segment and issues a duplicate ACK as expected.
This exact pattern is quite repeatable.
FreeRTOS is running happily during the evil pause (LED blinky task uninterrupted).

Why does the LwIP application take ~1.5 seconds to retransmit the data?

Again, thanks for your time and any hints...
Best Regards, Dave


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

reply via email to

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