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