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?
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