Slow transfers over long fat pipe

[Sorry if this shows up as a dupe]

We've tried this on several PCs running XP and 2K with identical results. Running the latest (988?) build of SmartFTP.

We regularly upload to a site about 16 hops and 40-50 ms away, with an OC3 on each end.

Using the Windows command line client, we see speeds of 15M+ bits/sec, roughly the same as we get from linux, Mac and Irix c/l clients.

But SmartFTP never exceeds about 1/10 of that, around 1.6Mb/s.

We've applied all sorts of TCP registry tweaks, etc with no change.

I suspect that SmartFTP is ignoring the available TCP window size and using its own value that is too small for this fast connection.

Is there any way to change that, or at least to diagnose this further?

Thanks for any advice.

--
Jim

The SmartFTP client doesn't alter the TCP windows buffer size. It's using the OS default values. The upload buffer is 2 kilobytes. This is the amount of bytes we input to the winsocket send() function per round. The pseudo code looks like this:

while(not EOF)



{



   read from file







   // winsock send



   byte buffer[2048];



   send(buffer, 2048);



}

The 2KB buffer turned out to be more efficient than other settings. With buffers > 16KB the transfer speeds calculation is not reliable for "normal" connections anymore.

Please feel free to contact me by a personal message (pm) for a debug session. If you use ICQ or MSN please include your id in the message.

Thanks
-Mat

The latest beta build reads the send and buffer sizes from the registry.
https://www.smartftp.com/download

The registry keys/values can be found in the following file:
https://www.smartftp.com/Products/SmartF ... 20Size.zip
The values are in bytes. The "Send Buffer Size" must be smaller or equal to the "File Buffer Size". The default values are in the .reg file.

Important: Changing the values is not recommended and in most of the cases it's doing more bad than good. The values do not affect any TCP/IP settings (window size, etc).

-Mat

mb wrote:The latest beta build reads the send and buffer sizes from the registry.

Important: Changing the values is not recommended and in most of the cases it's doing more bad than good. The values do not affect any TCP/IP settings (window size, etc).

-Mat

The last build you made shows tremendous improvement over the original. We started out taking 330 seconds to transfer a 65MB file. That sounds pretty fast until you realize that there's a 155Mb/s line between the two ends -- in theory it could take as little as 5 seconds.

At the time, the Windows FTP client was taking 40 seconds or so for the same transfer. This is after tuning the TCP stack using some registry voodoo found on the web. Unix, linux and Mac comand line clients all did about the same.

With this latest beta build, compression enabled, and after playing with the Settings > Transfer > Performance values, SmartFTP will reliably send our test file in 24 seconds -- more than 10x faster, and almost double the speed of ftp.exe.

It's been great having access to these test builds and having the opportunity to work with you to put this issue to bed.

I know that most people will never have to contend with optimizing transfers over a link with a high bandwidth-delay product, but
now with SmartFTP they have the handles to do it. Nice work.

--
Jim