• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 21 subscribers
  • Views 2662 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FTP is slow

syed ahmad

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

Parents
  • 0 in reply to syed ahmad

    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.

Reply
  • 0 in reply to syed ahmad

    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.

Children