Hi,
I can see TCP retransmission happens during files upload and download process time to time.
I am using Keil Middelware Network component to Put and get FTP files.
It is very very slow.
My total RAM is 128kb
I am currently using default TCP settings on keil.
As I understood FTP uses TCP.
1) Middleware version : Network version : 7.0.0.0 , FileSystem : 6.6.0 (We did not upgrade to latest FileSystem pack. We will try with latest pack updated soon.
2) Average Upload transfer speed = 31k/s and average Download transfer speed = 88k/s 3) upload is slower. 4) We use NOR Flash with Embedded File system.
5 ) I saw another issue. If I use two network connections on my Windows 7 machine. I used second network connection low priority ( I think) to connect to to my embedded device. basically I have two network interfaces on my windows 7 machine then FTP put and get will be more slower. I saw FTP connection is more slower.
Thanks, Naeem
TCP speeds are very much affected by amount of buffer RAM - how many TCP packets that you can "in the air".
A second connection that sends data means that you steal buffert RAM.
With large enough window size - i.e. number of packets "in the air", it's possible to get very close to the theoretical bandwidth of a network interface. With few packets buffered - or the special case of just a single packet - the lag will seriously reduce the bandwidth. With just a single packet buffered you get a stop-and-go protocol where the port sends out a single packet and then stops until the acknowledge has been received.
Hi Per Westermark,
Is there anyway I can tune my Windows FTP client or Keil FTP/TCP server settings to speed up.
It seems to me decent speed If I use only one network connection.
But I need to use second private network connection to connect my embedded device and FTP using second network connection. I do not specify to use second network connection using Win32 API. I guess It find automatically by iterating through all network interfaces.
I tried FTP FileZilla client as well. It is also slow using second network connection. which has low priority because Its interface Id is higher value.
Another point. I am not using any wireless connection. I am using only LAN wired connections.
When I wrote "in the air" I dint' mean wireless but number of frames being sent out but still waiting for acknowledge.
If the stack has enough RAM to use a window size of 10, then it can send out 10 consecutive packets before it stops and starts waiting for an acknowledge. If the acknowledge comes in for packet 1-5, then the stack can send out 5 more packets. If the acknowledge comes in for packet 1-10 then, the stack can send out 10 more packets. If the acknowledge is just for packet 1, then only one packet slot was released so the stack can only send out one more packet.
If the stack has to do a full stop-and-go, then it can only send out packet 1. Then wait for acknowledge on packet 1 (or maybe timeout in which case the packet is resent). First when packet 1 is acknowledged can the stack send packet 2. This means that anything that affects the full turnaround time from send+receive+processing+send of ack+reception of ack+reaction to process the ack+reaction to start sending next packet will decide how long it will take between each transmitted packet. This also means that if your main loop or your task scheduling adds a couple of ms of reaction time, these ms will directly be translated into time when the networking hardware is stalled with no outgoing data.
The more outstanding packets the TCP/IP stack has RAM to support, the better the TCP/IP stack will be able to hide the effects of reaction times. This means that with enough outstanding frames, it's possible to use links with many seconds ping time and still have almost perfect bandwidth - because the stack can send out and buffer enough data speculatively to keep the interface busy the full time until the ping time allows the acknowledges to start arrive.
I guess I use HTTP put to send file . I will still face same issue. because underlying cause is TCP transmission is slow.
If any solution let me know. Is it related with out device only have 128 KB RAM.
Potential slow TCP performance in Network version 7 has already been corrected. If you are using an FTP client, slow TCP performance might affect your application too. Please ask support for the updated libraries.
Hi ,
I am using Board : STM32F207VET6
RAM : 128 kb ROM : 512 kb.
I am using latest Keil MDK Network , version = 0.10.0( 2015-04-24)
I am using latest Keil Middleware , version = 7.0.0 ( 2015-12-08)