Free user limited in speed?

I use a FTP client to upload data to my Popcorn Hour media tank. Typically files of 4GB are send to the PH. Normally it takes take appr. 15 minutes to complete. That is, when I use any other FTP client than SmartFTP. Using SmartFTP will increase my upload time from 15 minutes to 2+ hours!!!

Am I correct in assuming that the free version of SmartFTP is crippled up/download speed-wise and that purchasing the program will allow me to transfer at maximum speed (I have a 1Gb infrastructure)?

Best regards,

Gastel

There are no speed limits in the free edition. SmartFTP uploads as fast as possible.

There are no speed limits in the free edition. SmartFTP uploads as fast as possible.

That is good to hear. Then why is it that only SmartFTP transfers with a speed of appr. 500Kb/s and (all) others do the same job with appr. 5000Kb/s? That is a factor 10 faster! B.t.w. I have set the maximum speed at "0" which indicates a "no limit" transfer speed. Are there certain settings that I should pay attention to? At this moment, I use the default settings.

Best regards,

Gastel

[edit typos]

That is something we need to figure out. Please post the system information from the menu: Help->About "System Information" dialog.
And then also post the log from the actual transfer. You can get it by double clicking the file in the transfer queue.
What are you download speeds?

Did anyone look at this?

I find I get 4.4MB/s download speed and only 330 KB/s upload speed. This is on a long distance WAN network. Upload should be about half of download speed and is indeed so with a different FTP tool.

Try this:
https://www.smartftp.com/support/kb/how- ... f2558.html

But by default SmartFTP transfers the files as fast as possible. Please also note that other programs display the speed in kilobit per second, so the value displayed is by a factor 8 higher.

Yes, I had already found it. As to the speed difference, I usually also 'time' how long it takes, using the same file every time. The initial download was about 8minutes, with the receive buffer set to the default 128 and in the log shown to negotiate to 1024. I upped the receive buffer to 2048 and brought it down to 3minutes to download the file.

The delay is about 80ms, while the capacity of the line is about 40mbps.

With upload, changing the buffer size basically acted as if I hadn't changed anything. The capacity of the line to uplaod is about 20mpbs, so its less, but this upload was going to take 30minutes.

I am using SFTP over SSH.

Retested today:

3minutes to download, using 2048 as the tcp send/receive buffer window (with auto-tune enabled).

Since I previously testing 2048 as the tcp send window, I now set it to a more modest 512 (instead of the 128 default), to see if it would affect upload rate. No change in upload rate, average speed listed as 318KB/s, and that 600mb file will take about 30minutes.

To eliminate the variables alltogether, I threw everything out and created a new profile with default settings.

Result:
Upload speed avg 313KB/s, estimated duration ~32minutes.
Download speed avg 1.45MB/s, estimated duration ~7minutes.


Please note, this particular setup can upload much faster, this was confirmed via a different SFTP tool, which I reran within minutes of your tool and was able to upload at 2.2MB/s rate (taking about 4minutes for that 600mb file).

Try it with FTPS (FTP over SSL/TLS). It's equally secure but usually/always faster than SFTP over SSH.

1. The server is SFTP only.
2. The 'faster' thing is only due to encryption and that's a non factor over such distances - the CPU has plenty of extra time to compress everything and uncompress, because the packets come far more slowly than locally. This is confirmed by monitoring CPU via task manager.

Your product's broken when it comes to upload speed, quite likely related to the send buffer not adjusting. You should submit a bug report to your developers and have them look into it. Compare your upload rate to yzy.

More research.

When I use a default properties connection (the socket receive buffer is only set once), it shows:
[12:54:39] Host Key Algorithm: ssh-rsa
[12:54:39] Client to Server Encryption: aes128-ctr
[12:54:39] Server to Client Encryption: aes128-ctr
[12:54:39] Session MAC: hmac-sha1
[12:54:39] Client to Server Compression: zlib@openssh.com
[12:54:39] Server to Client Compression: zlib@openssh.com
[12:54:39] Requesting service "ssh-userauth".
[12:54:39] RTT: 293.017 ms
[12:54:39] Authentication request. Method: none
[12:54:39] Server supported authentications: publickey,password,keyboard-interactive
[12:54:39] Authentication request. Method: password
[12:54:39] User authentication successful.
[12:54:39] SSH session established.
[12:54:39] Connected to 123.30.146.80.
[12:54:39] Detected Server Software: OpenSSH
[12:54:39] Opening channel 0.
[12:54:40] Channel successfully opened (Local=0, Remote=0).
[12:54:40] Requesting subystem "sftp" (Local=0, Remote=0).
[12:54:40] Sending FXP initialization. Protocol version=6.
[12:54:40] SFTP protocol version 3
[12:54:40] Resolving path "/export/home/agerm".
[12:54:40] Path successfully resolved to "/export/home/agerm".
[12:54:40] Uploading file to "/export/home/agerm/junk2.zip".
[12:54:40] StartPosition=0, EndPosition=0.
[12:54:43] Socket receive buffer set to 262144 bytes.



When I manually change the setting in the favorites for transfer to change the socket buffer sizes, the log does not have the last line:

[13:00:01] Host Key Algorithm: ssh-rsa
[13:00:01] Client to Server Encryption: aes128-ctr
[13:00:01] Server to Client Encryption: aes128-ctr
[13:00:01] Session MAC: hmac-sha1
[13:00:01] Client to Server Compression: zlib@openssh.com
[13:00:01] Server to Client Compression: zlib@openssh.com
[13:00:01] Requesting service "ssh-userauth".
[13:00:01] RTT: 290.645 ms
[13:00:01] Authentication request. Method: none
[13:00:01] Server supported authentications: publickey,password,keyboard-interactive
[13:00:01] Authentication request. Method: password
[13:00:02] User authentication successful.
[13:00:02] SSH session established.
[13:00:02] Connected to 123.30.146.80.
[13:00:02] Detected Server Software: OpenSSH
[13:00:02] Opening channel 0.
[13:00:02] Channel successfully opened (Local=0, Remote=0).
[13:00:02] Requesting subystem "sftp" (Local=0, Remote=0).
[13:00:02] Sending FXP initialization. Protocol version=6.
[13:00:02] SFTP protocol version 3
[13:00:02] Resolving path "/export/home/agerm".
[13:00:02] Path successfully resolved to "/export/home/agerm".
[13:00:02] Uploading file to "/export/home/agerm/junk2.zip".
[13:00:02] StartPosition=0, EndPosition=0.



The lack of last line entry listing what the socket buffer size is odd.
Compare to this one. It's the same 'favorite' with both send/receive buffers set to 2048, as in the prior example. In order to get a fresh log with all the exchange information, I had to close out SmartFTP and restart the connection. Otherwise its the same. It contains a far larger negotiated buffer.

[13:08:15] Host Key Algorithm: ssh-rsa
[13:08:15] Client to Server Encryption: aes128-ctr
[13:08:15] Server to Client Encryption: aes128-ctr
[13:08:15] Session MAC: hmac-sha1
[13:08:15] Client to Server Compression: zlib@openssh.com
[13:08:15] Server to Client Compression: zlib@openssh.com
[13:08:15] Requesting service "ssh-userauth".
[13:08:15] RTT: 286.669 ms
[13:08:15] Authentication request. Method: none
[13:08:15] Server supported authentications: publickey,password,keyboard-interactive
[13:08:15] Authentication request. Method: password
[13:08:15] User authentication successful.
[13:08:15] SSH session established.
[13:08:15] Connected to 123.30.146.80.
[13:08:15] Detected Server Software: OpenSSH
[13:08:15] Opening channel 0.
[13:08:15] Channel successfully opened (Local=0, Remote=0).
[13:08:15] Requesting subystem "sftp" (Local=0, Remote=0).
[13:08:15] Sending FXP initialization. Protocol version=6.
[13:08:15] SFTP protocol version 3
[13:08:15] Resolving path "/export/home/agerm".
[13:08:15] Path successfully resolved to "/export/home/agerm".
[13:08:15] Getting attributes of "/export/home/agerm/junk.zip".
[13:08:16] Attributes successfully obtained.
[13:08:16] Downloading file "/export/home/agerm/junk.zip".
[13:08:16] StartPosition=0, EndPosition=0.
[13:08:20] Socket receive buffer set to 4194304 bytes.

SmartFTP doesn't use "pipelining" (yet) for SFTP uploads. That is the reason the upload speeds are not always optimal for connections with a high BDP product.

What do you mean by pipelining? Are you referring to TCP Sliding windows? Your downloads are good and the adjustability feature is something that's awesome for WAN use. Just need the same thing for uploads. Theres' very little technical difference between the two so I figured you just overlooked abit of code or accidentally commented that part out.

pipelining: Sending multiple packets without waiting for the ack. This is something specific to SFTP and shouldn't be necessary if the SFTP server is configured correctly (large SFTP packet size). We already do this for SFTP downloads (requesting multiple data packets at the same time if the SFTP packet size is not big enough).

The TCP sliding window that can be controlled with the socket buffers is on a different network layer. It's the same concept but on a different OSI layer.

The SFTP server is Unix based running the latest OpenSSH version with HPN Enabled patches applied. It's also been tuned but the large packets don't do the trick by themselves.

Do you know when you anticipate having pipelining working on uploads as well as downloads?

Thanks.

Update: Received a test set of files from MB and tested it and verified the speed improvement in upload.

Thanks MB!

The new version is available now:
https://www.smartftp.com/download/

I wanted to verify the latest version but the trial ran out. Any chance I can get say a 7 day valid key?

Thanks.

The new version is not different from the version that we have provided to you previously.

the prior version was me updating a couple of files. I just want to verify that its the same as the customer will get. I've had bad experiences in the past and I'd spend the 10minutes to test/verify it than to find out I'm wrong.

1 day trial is fine too. Literally just need to run it, test it, and we'll all go home happy. You can give it to me and then blacklist the trial license after a day. Not trying to scam ya, just trying to do my admin job.