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

[address@hidden]

Am 15.03.2019 um 22:56 schrieb Dave Nadler:
> Thanks Sergio, more info below...
>
> On 3/15/2019 10:57 AM, Sergio R. Caprile wrote:
> > OK, I'll try to be more precise.
> > ST driver code wasn't properly handling receive interrupts from the
> > Ethernet controller. They just took the first frame in the buffer
> > without thinking more could have arrived since the interrupt fired.
> > Those frames remained there sleeping until a new one arrived, causing
> > delays and frame loss.
> > This is supposed to have been fixed, but from time to time I see people
> > telling the story that revision X for hw A has the problem that was
> > fixed in revision W for hw B, so...
>
> I'll go study this. First look at the ISR seems to assume one buffer 
> received per
> DMA-completion interrupt, but the documentation clearly says there
> can be more than one. Looks bad... I'll research and report back.
>
> > I would first analyze a traffic capture to determine the reason for the
> > low throughput, there can be delays, lost frames; you could have a
> > broken driver, a broken port, a broken application...
> > You should use a known-to-work application (one of those in the apps
> > directory or in the contrib tree, I used a netio long ago and I guess
> > there is an iperf there now) so you can rule that out and check for
> > driver/port issues.
> > Most people use Wireshark, pcap or pcapng is OK. Post a link if possible.
>
> Here's the capture (same session as screen image posted earlier):
> http://www.nadler.com/backups/20190227_Lwip_pause.pcapng
>
> 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).
>
> 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?

In absence of more dup-acks (there's only one at that time, packet 
#4317), there's only the rto timeout that triggers retransmissions. 
Without having a look at the spec or at the code, I can't tell if these 
1.5 seconds are expected or not. They certainly seem too long for a 
decent, robust communication flow, but then again, you have a somewhat 
"untypical" ping-pong of very short data. Maybe tcp is just not up to 
what you want (in terms of "real-time"). Protocols like Modbus-TCP 
implement retries on top of TCP, maybe that's an option for you?

Regards,
Simon

> > Cheers
>
> 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
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users