Hi,

I'm having a problem using WinSCP from my Windows XP machine to a Mac OS X machine. The two systems are sitting next to each other, plugged into the same gigabit Ethernet switch. If I transfer a file from the Mac to the PC using WinSCP, the file transfers extremely slowly (about 20KB/sec). Frequently if I transfer a large file, the connection will drop entirely before the transfer finishes.

This doesn't occur using other programs to transfer the file between the two machines. In particular, if I use the Cygwin command-line SCP client, the file will transfer at multiple megabytes per second, as I would expect. Copying the file from a Samba share on the Mac is also quite fast.

What could be causing this? Clearly the CPU and network bandwidth is available to do the transfer much more quickly, since the Cygwin SCP client transfers the file hundreds of times faster. If there's an easy way to fix this, I'd definitely like to know, since the WinSCP interface is quite a bit more convenient than the Cygwin command line.

Thanks for any help,

-- mpb

1) Try different transfer protocol (SCP/SFTP).
2) Try different encryption algorithm.
3) Try to enable compression.
_________________
Martin Prikryl

Dear prikryl,

I've read topics about this problem. All solutions are described in 3 tips above.
I've tried to do them and there's no result !!

Client CPU loads 2%, server one 3%, ethernet 10MB/s
Speed is 12kB/s - it's unacceptable !!
Another traffic for the server and passing it by reaches the real bandlimit, but not winscp
What should I do, because if this condition isn't taken under considiration this programm is the best in its own class. !!
_________________
sometimes they come back

Can you try other SCP/SFTP client to verify that the problem is on WinSCP side?
_________________
Martin Prikryl

I've tried to.

I couldn't found any GUI apps for Win32 with no critical bugs in addition to poor interface.

I used command line app:

OpenSSH for Windows
http://sshwindows.sourceforge.net/

The result was:
client CPU loads 3%
server one 8%
on the same ethernet 10MB/s

the speed was 90kB/s (average)

Tell the true it's unacceptable too (but I can find it as a success) but it's not 12kB/s

It becomes interesting for me where is the problem. I seem to use FTP instead of SCP/SFTP in future for my purpose but... why it works so ?
_________________
sometimes they come back

What critical bug do you mean?
Have you tried PSFTP/PSCP command-line clients?
_________________
Martin Prikryl

Hanging... Disconnecting...
(Note (read above), This is not about WinSCP !!)


Yes, I've written above...

_________________
sometimes they come back

No you haven't, or I'm blind
What were the results?
_________________
Martin Prikryl

Sorry, I don't think so... but I can begin worrying about you
The results has been written by me up this topic...

SSHwindows
http://sshwindows.sourceforge.net/
is the comand line client !! It consists of two command line programs (that named similary to UNIX ones) - scp and sftp...
_________________
sometimes they come back

OK, but I have aked about PSFTP and PSCP (note the P at the beginning).
_________________
Martin Prikryl

i have the same prob. winscp is going about 20kb/s from a multi-backboned server located @ dallas, tx while the ssh communications ssh client is going 100Kb/s on my 1Mbit cable connection

i am discussing the client's "download" feature (from server to client)

additional info to the post above:

i am located in UPC network, Prague, Czech republic, 1MBit
the server is in Dallas, TX, USA, Multi
(ping is about 150ms to the server)

using SSH Com. SSH client's SFTP is 5 times faster (100kb/s) than using WinSCP. (20kb/s) when downloading files from server

WinSCP ver 3.6.1 used - sorry for this inconvenience... if it's not the newest version =)

tell me if you need some other nfo

People occasionaly reports that WinSCP is slower then other SSH clients. So far I have not been able to find out why. I do regularly comparison tests, and transfer speed of WinSCP is on average the same (sometimes little bit faster, sometimes slower). I do not know where is the difference between my test systems and systems of user reporting the problem
_________________
Martin Prikryl

Using cygwin sftp, I can copy over the Internet maxing out the bandwidth of the server (128kbps).
Using WinSCP, it only uses 65% of the available bandwith. I changed the crypto from AES to DES just to try and now I am using 72%. The server is in Argentina and I'm in India (for a short time thank God).
Thanks for a great tool though. A caballo regalado no se le miran los dientes.

I agree. There is a problem with the client.

1) establish connection from client A to server X.

2) copy a large (60GB) file from client A to server X.
speeds of 8-10MB/s are transfered.

3) copy the same file from server X to client A using the same connection.
speeds of 400Kb are registered.

4) copy the same file using CLI scp (not winscp) from server X to client A results in a 8-10MB/s.

server X is using the current OpenSSH on RHEL AS.
client A is using the current WinSCP on XP.

The network is fine. Other client software works fine on the same client machine. It must be a WinSCP problem.

Unless my logic is flawed

Same problem here...
I use winscp to copy files from my XP desktop to and from a server (running F-secure ssh server) connected to the LAN.
However, the speed is terrible so I conducted a couple tests:
winscp<----75kb/s----->f-secure server
psftp<----75kb/s----->f-secure server
Securefx<----900kb/s---->f-secure server
ssh tectia<----900kb/s---->f-secure server

Looks like the problem lies in the putty code...

cheers

Hi,

i have the same ptoblem. Winscp are very slow...

Any idea to fix this problem?

me too: 100mbit --> 4mbit ;(
nevertheless it works. So thanks anyway

Hello Martin,
Very nice program! Maybe what people are experiencing is the Nagel Algorithm which delays sending packets of data until a certain amount is ready or a certain amount of time has passed.
http://www.fluent-access.com/wtpapers/ip-test.html
I believe you can disable to test in C with:
#define __NO_NAGLE__
Hope that helps and keep up the good work!
Bill
wwarnerwscp at telsys.com

Isn't it reversely? At least Putty docs says that the nagle algorithm may speed up transfers. Currently it is disabled for WinSCP. I can try to enable it.
_________________
Martin Prikryl

An associate ran into a problem where sustained tranfer rate for large files was fast but for numerous small files it was dog slow and it turned out to be Nagel, or at least it seemed to be the case because turning off Nagle 'fixed' it but it seems if you already have it off then it must be something else.. Btw, found more info that might help if it is Nagel:
http://tangentsoft.net/wskfaq/intermediate.html#disable-nagle

I've experienced this same problem with very slow rate with WinSCP when sending files from another location back to my location (1.1Mbit DSL there & 768Kbit fractional T1 here) but it was VERY fast when I was doing testing when sending to the same machine (send/rec on itself). Not sure if that helps..
Regards,
Bill
wwarnerwscp at telsys.com

I was wrong, the nagle is enabled in WinSCP. I have tried to disable it. The result was 3 times slower transfers. but I was testing it on one large file. I admit that on transfer of small files it may have possitive effect.
_________________
Martin Prikryl

We have the very same transfer performance problem. It seems also, that it's related to connections, when the server and the client are far from each other (150+ ping). As if the client was waiting too often for acknowledges of some kind.

I am also experiencing a drop off in speed when using WinSCP. My server runs a SSL FTP site, both SFTP via WinSCP and the FTP site are using AES encryption. When transfering via WinSCP using SFTP it seems to max out about 190kB/sec. Using SSL FTP it is almost triple this.

My speed is about 20-30% slower than other SFTP clients when transfering big files. But when sending small transactions (delete or small files) the speed is about 5-10 times slower!

Somehow the sending, receiving the result and make a next command take a lot of time with WinSCP when other software is just doing the same in few milliseconds.

WinSCP is wonderful program, but this is serious problem for totally success or failure.

I tested pscp.exe and its speed was about 2-3 times better than WinSCP in small files, but the speed was also very slow when compared the eg. Vandyke SecureFX

SCP is a lot faster for me than SFTP (900KB/s vs 120KB/s)

Heres the setup:
Ubuntu (hoary) as the ssh server (fresh install).
I copied a 900 meg zip file using winscp to my laptop, and also copied the same file to a debian system. both computers plugged into the same switch as the server (100mbit).

The debian box is a 400mhz Psomething
The Win computer is xpsp2 (1.6ghz etc)
The ubuntu server is a 2.6ghz.

The transfer to the debian box went at about 2.5MB/s and took just under 4 minutes
the transfer to the windows box is taking considerably longer (and in fact hasnt finished STILL) (i dont see a way to see transfer rate in winscp?) im guessing less than 300kb/s.
Transfered again using putty pscp 0.57 and got 400kB/s.
Transferred again using winscp forced to scp mode, and it went significantly faster (again, some rate stats would be helpfull) but not as fast as to the old slow debian box.

So, something seems wrong with Windows, or both pscp AND winscp. I suggest some profiling during transfers to see where its spending its time, and since openssh scp is open source, taking a look at how they do it faster.

Long and short is, dont use sftp mode if you can help it. Maybe the 'sftp with scp fallback' option should be the other way around, at least for big files.

Hope this helps.
-Rubin

P.S. the FAQ claims winscp is slow due to CPU bottleneck.. While that is definately the case in scp mode, it doesnt seem to be the problem with sftp mode. You may want to clarify that.

What version of WinSCP are you using? As you do not see transfer speed I suppose that you use background transfer with version prior to 3.7.2. By coincidence it was exactly the version that introduced significant acceleration of SFTP protocol.
_________________
Martin Prikryl

Hi there,

Hope this is the right thread to ask:

I'm using WinSCP (thnx to the dev team! ) to transfer files over my LAN from WinXP to Gentoo and vice-versa. I haven't been able to get speeds higher then 3 MB/s both directions.
Does anybody here use WINSCP on a LAN and is able to get more then 3 MB/s transfer ?

thnx.

I can confirm that WinSCP is slow on the otherwise fast network. Home connection speed is approximately 1Mbps, but with high latency for small packets (ssh sessions are rather clunky).

PSCP itself is slow, too. Tried with SCP, SFTP, but no difference.

If I get around to install Borland C++, I can help with debugging.

Andrei, andreie@no.spam.ee.

Do you know of faster SSH client then WinSCP/PSCP?
_________________
Martin Prikryl

I've tested SSH.com client and WinSCP and SSH is faster (22,1kb/s vs. 18kb of WinSCP). Tested with DSL with 192kbit up and AES 256 and compressed.

I've thought that you see greater difference
Anyway, of course there are definitelly things to improve.
_________________
Martin Prikryl

Hi, I'm experiencing similar results as other people. With a 2.3megabit dsl I get about 200K uploading with scp from cygwin. and I get about 60KB uploading with WinSCP, I couldn't get pscp to connect (I didn't try very hard)

Downloading with WinSCP is fine, I get about 200KB.

I'm useing the latest beta version, 3.8 Build 312.

The server is debian 3.1

I confirm these results with 3.8.0.

With a 2.0 megabit dsl I get about 20KB uploading/downloading with WinSCP.

Any workarounds?

I've noticed the same here. Seems to be related to latency. The site I'm trying to upload to has about 200-250ms latency. With 512Kbs upload on my ADSL I only get transfers of 5-8KB/s (40-64Kbps) - something is definately wrong. Other SFTP clients are better but no where as good looking and feature packed

Can you try PSFTP?
_________________
Martin Prikryl

Yes, Tunnelier from bitvise works for me much faster on 100Mbit LAN!
http://www.bitvise.com/download-area.html

Client: Win XP SP2
SSH server: SLES 8/9
WinSCP v.3.8.1 - max. 1.6 Mbyte/s server client and 2.5 Mbyte/s vice versa.
Tunnelier v.4.15a - 8.5 Mbyte and 10 Mbyte.
AFAIK, Tunnelier bases on PuTTY sources.
What could be the difference?

Best regards
Al

WinSCP is great, but I must admit it is slower (50%) than ssh.com
I get 2.2MB/s vs 4.5MB/s with a 1Gig file
I sure hope you will find a solution to this, they are features I realy like in WinSCP.

fyi
I get 4.5MB/s with http DL (Firefox)
I get 2MB/s with FileZilla sFTP .. same as with WinSCP

cheers,
PetitQuebec

The original poster's problem absolutely yells "duplex settings". A duplex mismatch on the link can produce exactly that failure pattern.

As for winscp performance - I also have trouble with it. On a celeron 600 (my work pc) I have 100% CPU load at ~600kB/s with AES, and ~1400 with blowfish.

Openssh Unix-Unix on lesser hardware is _way_ faster.

Just got Tunnelier going and it rocks .. more than a douzen tests and 100gigs or transfert .. a solid 14-16MB/s transfert rate
My life will never be the same, thanks "Al"

PetitQuebec

I'm not yet prepared to blame your client Martin. Slow SFTP/SCP/ssh x11 forwarding seems to be the norm across all server types and clients I have tried (most versions of Linux, Windows and Solaris), from ssh1 back in the days before it was "Open". There are a heck of a lot of variables for the sys-admin to (mis)configure on any server and most SSH installations seem to suffer for it.

For the rest of the people above who were talking about slow upload speed on their DSL/ADSL... DSL (misnomer) and ADSL (dls is this too actually) stands for Asyncronous Digital Subscriber Line. Asyncronous means not the same speed in both directions, your typical 3.5 - 5mbps is only downstream, upstream is 800kbps (bits per second) on both. So the best you could possibly hope for on a dsl is 100kilobytes per second on upload, from any application. Cable is often worse and 40-60kilobytes upstream is common.