Re: [lwip-users] TCP retransmission flooding at end of stream

[Michael Steinecke]

address@hidden wrote
> Which version of lwIP are you using? Do you know that we support TCP 
> window scaling by now (LWIP_WND_SCALE)?

Indeed, i forgot this one. Its the version provided by the STM32CubeMX tool.
Diff shows its identical to LWIP 1.4.1. I didn't knew that. I guess you
refer to patch 7858? I will apply it.


address@hidden wrote
>> - I decreased the TCP timer intervals from 250 ms to 10 ms. A even higher
>> rate tends to produce a lot of retransmissions.
> You should really not need to do this! I rather expect more problems 
> than anything being solved. Especially when your main issue is sending 
> data, not receiving.

I've tested again with 250 ms - The only difference in the behavior seems to
be a much lower transmission rate. I achieve about 200 kB/s.


Krzysztof Wesołowski wrote
> I am not sure why you decided to go in such extreme direction with your
> changes.
> 
> We are almost able to saturate 100MBit connection (>8 MB/s) and upload
> about 2MB/s from SD Card on STM32F407 with RMII attached PHY (Some Micrels
> KSZ...)
> 
> Are you using some WiFi in your setup? With Ethernet networks we only
> needed to tune memory in lwipopts, and there was no need to change types
> and/or polling interval.
> 
> Have you benchmarked if the need for optimization really is within LwIP
> related code?

I've started about a month ago porting our STM32F1 based board to the new
MCU. The old design had a WizNet W5300 Ethernet IC, implementing the TCPIP
Stack in HW. Therefore I'm absolutely not sure, my changes are going in the
right direction. However, initially I struggled on very high roundtrip times
and a low throughput of about 5 kBit/s. The PC seemed to resend
unacknowledged packets after about 200 ms. Also, I'm using the tcp_poll
callback to en-queue new data to the stack, in the context of the
tcp_thread. For both reasons it seems natural to reduce the intervals. On
the other hand, having a bigger SND_WND allows less memory management,
outside of the stack, which seems to be quite efficient. Now i can achieve 2
MBit/s (until the error occurs) so yes it seems to be influenced by the
stack. (5 kB -> 70 kB was achieved, due to the zero copy driver)

On the other hand, I guess there still several other regions for
improvements.

Thanks!



--
View this message in context: 
http://lwip.100.n7.nabble.com/TCP-retransmission-flooding-at-end-of-stream-tp23275p23294.html
Sent from the lwip-users mailing list archive at Nabble.com.