performance issue (2)

I already add a topic on June 21th concerning a performance issue when downloading files, and curiously it is the only post without any answer. See my previous topic below.
Winscp has great functionalities but I am very disapointed of the poor transfer rate when downloading files.
Please, can you try to give me any information to understand this topic

my previous topic
" I am using Winscp 4.02 with sftp.

I did some performance measures and I observe different byte rate transfer according to transfer direction:
server -> winscp (get): byte rate transfert = 300 KByte/s
winscp -> server (put): byte rate transfert = 2000 KByte/s

conditions of test:
direct link beetween server and local winscp ( no external charge , no hub ...)
encryption algorithm = AES (same result with blowfish)

I did the same measures with ssh secure shell version 3.2.9 and the results where:
server -> local (get): byte rate transfert ~ 2000 KByte/s
local -> server (put): byte rate transfert ~ 2000 KByte/s

Have you an explication of such a difference ?
best regards "

Can you try that with 3.8.2?

I tried with the 3.8.2 version and the results are approximately the same.

Changing AES to blowfish encryption type results in the same speed rates.
Actually, they're better in the winscp->server direction but the same for the other direction which interests me much(server->winscp).

My server OS is windows XP.
I've tried with a computer under windowx XP and with windows 2000.
The results are the following:

WINDOWS XP:
server -> winscp (get): byte rate transfert = 300 KByte/s
winscp -> server (put): byte rate transfert = 2000 KByte/s

WINDOWS 2000:
server -> winscp (get): byte rate transfert = 900 KByte/s
winscp -> server (put): byte rate transfert = 900 KByte/s

But my application has to beon WINDOWS XP...

Do you know what this difference is due to ?

Is there a buffer size or something like that whe could modify ?

Thanks.

I found this in the topic named very slow transfer speed:

Some tests on a LAN (server is running OpenSSH 4.5)...
- WinSCP/3.8.2 gets about 2500 KB/s over SCP
- WinSCP/3.8.2 gets about 400 KB/s over SFTP
- SSH.com Client/3.2.9 gets about 600 KB/s over SFTP
- CuteFTPPro/8 gets about 250 KB/s over SFTP
- PuTTY PSFTP/0.56 gets about 330 KB/s over SFTP
- PuTTY PSFTP/0.58 gets about 100 KB/s over SFTP
- PuTTY PSFTP/0.59 gets about 1100 KB/s over SFTP

So...

1/ The difference between SFTP and SCP was a lot bigger than I had expected.

2/ Between 0.56 and 0.59 of the PuTTY client, the speed went up by 3x (0.58 was unusually slow; I think it's buggy). Still slower than SCP, but much better than any of the other SFTP tests.

3/ According to the changelog for version 6722 of sftp.c in the PuTTY CVS, the the 3x speedup is caused "simply by upping the packet sizes and maximum in-flight packet count." The WinSCP code and the PuTTY code are so very different that I can't seem to find anything remotely similar; you are much more familiar with your code than I am; are tweaks like this feasible for WinSCP?





WinSCP does it the same, but with different numbers.
You can alter one of these via options SFTPDownloadQueue and SFTPUploadQueue in the respective session section of WinSCP configuration. The default value is 4, try something larger (like 10).
_________________
Martin Prikryl


So I tried to compile winscp and to modify the SFTPDownloadQueue and SFTPUploadQueue parameters.

Unfortunately, the speed rate is still the same...

Has someone an other idea ?

Has someone an other idea ?

None. Sorry.

Do you know how the performances are different under Windows 2000 and under Windows XP ?

I found on the web that we could improve TCP parameters by enabling RFC1323 options in the windows register.
Have you heard abour this ?

Thanks.

CG wrote:

Do you know how the performances are different under Windows 2000 and under Windows XP ?

I found on the web that we could improve TCP parameters by enabling RFC1323 options in the windows register.
Have you heard abour this ?

I haven't seen such difference before.

Please tell if you have an idea to improve the download/upload speeds.

300Ko/s is very boring and we would maybe change foran other software.

Thanks.

There must be something in common among all of the machines with poor performance. It's so commonly reported here.

Perhaps also most people just don't notice figuring something else on the network is slow. It's absurd that so many other clients are so much faster, yet there seems to be this feeling that it's not WinSCP... no offense meant to the authors, there just must be something in common that can be resolved, either in the code or a setting on the user machines.

I don't think there's a feeling that WinSCP is infalliable, it's just that Martin's not a TCP/IP expert (I don't think, anyway) and I don't think he has any ideas what else he can reasonably do to make WinSCP faster. If you (or anyone who reads this thread) have patches for WinSCP or PuTTY that improve transfer speed, send them to the PuTTY authors or to Martin. I'm sure they'd be happy to see their software made faster.

For me, PuTTY (and by extension, WinSCP) has never compared favorably with other software in terms of throughput. But the user interface of PuTTY and WinSCP is head and shoulders above everything else, so I use them anyway.

[Martin, sorry if I'm putting words in your mouth here.]

TS wrote:

I don't think there's a feeling that WinSCP is infalliable, it's just that Martin's not a TCP/IP expert (I don't think, anyway) and I don't think he has any ideas what else he can reasonably do to make WinSCP faster. If you (or anyone who reads this thread) have patches for WinSCP or PuTTY that improve transfer speed, send them to the PuTTY authors or to Martin. I'm sure they'd be happy to see their software made faster.

For me, PuTTY (and by extension, WinSCP) has never compared favorably with other software in terms of throughput. But the user interface of PuTTY and WinSCP is head and shoulders above everything else, so I use them anyway.

[Martin, sorry if I'm putting words in your mouth here.]

Oh, I understand that (the first paragraph, but there are seems to be some sort of feeling that just changing the encryption algorithm is a silver bullet, or that the problem is far less widespread that it is. I'm not saying it's an easy to solve problem, by any means, but 80% slower than comparable apps feels like a configuration issue more than anything. And it's not that it's slow -- it's obvious that it can perform faster, but it performs at something of a ratio to what it seems like it should. (e.g. people that should be getting 8MBps get 1-2 MBps, people that should be getting 700Kbps get 100 KBps, etc.)

As for the second paragraph... that's where I'm at, too. Sure, I can use the command line tools that are faster and, in fact, I may. But for the others in my team, they can't so there isn't much I can do for them other than try to figure out if there is some sort of configuration issue causing the slow down.

On issue with forums is so often questions go unanswered in writing because the original person asking fount the problem and thus never checked back. I'm hopeful that someone might have an answer.

Thanks!

I cannot added anything more to the discussions apart what is written in the FAQ and what TS has summarized above (thanks).

This issue has been added to tracker.