[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] TCP retransmission flooding at end of stream
From: |
Michael Steinecke |
Subject: |
Re: [lwip-users] TCP retransmission flooding at end of stream |
Date: |
Wed, 17 Sep 2014 02:21:27 -0700 (MST) |
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.
Re: [lwip-users] TCP retransmission flooding at end of stream, Sergio R. Caprile, 2014/09/19
Re: [lwip-users] TCP retransmission flooding at end of stream, S G, 2014/09/19