This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: very poor cygwin scp performance in some situations

----- Original Message ----- From: "Corinna Vinschen"
Yeah, I'm just slightly annoyed about the "Cygwin is slow" routine on
this mailing list.

I would not say Cygwin is not slow persay but there issues in certain areas which have issues. This is what I was trying to highlight and as such hopefully get some movement on, which we can all then benefit from.

However, the performance of ssh/scp is not a Cygwin problem per se.
Note that the poor performance of ssh/scp is a well-known fact, which
has been discussed pretty often on the ssh developers list, and which
has different impact on different OSes.  The above hpn patch was
supposed to tackle exactly this problem.  It's not integrated into
mainline so far, because security is of a bigger concern than speed for
the OpenSSH developer team, which should be immediately understandable.

scp performance is an issue yes, but only when your looking at high latency or very high bandwidth links and as you've rightly pointed out, work has been done in this area by the hpn patch. This however is not the issue at hand.

What I believe we're looking at is low latency, averge bandwidth 100Mb/s
network which presents an issue uniq to the cygwin compile of ssh / scp.
In addition to that it's not, as you've seen, always the case depending on
direction etc, so cygwin definitely has the potential to be significantly quicker.

I made some tests locally and my default numbers (118 Meg file) are

 From Linux to Cygwin, started on Linux:  9.1MB/s
 From Linux to Cygwin, started on Cygwin: 1.2MB/s

It turns out that three factors limit the speed on the client side:

- The worst of all is ssh itself.  When reading blocks from the network,
 it uses an 8K buffer.  Whatever you try with setting different socket
 buffer sizes or disabling the Nagle algorithm, nothing has any
 interesting impact if not ssh's own buffer is raised in size.  By just
 setting the buffer to 64K (in the ssh source file clientloop.c,
 function client_process_net_input, line 575), the above copy started on
 Cygwin suddenly races along with 4.2MB/s.

I just tried the same thing here and get:
From FreeBSD to Cygwin, started on Cygwin: 8.7MB/s up from
6.4MB/s unpatched.

Thats a good improvement, unfortunately it has no bearing on the key
test here which is:
From Cygwin to FreeBSD, started on FreeBSD which is still 731KB/s

- The default WinSock send/recv buffer size is apparently 8K.  This is a
 quite small buffer for bulk data transfer.  Raising this buffer to 64K
 (setsockopt's SOL_SOCKET/SO_RCVBUF option), too, results in a
 throughput of 5.9MB/s.

 Note that the performance suffers again, if the socket buffer is
 smaller than the application buffer.

I'd be interested in trying this, where abouts did you set this in the ssh code?

- Disabling the Nagle algorithm (setsockopt's IPPROTO_TCP/TCP_NODELAY
 option) doesn't really have a lot of impact, but it's slightly
 noticable.  The throughput goes up to 6.1MB/s.

Again could you tell me where you set this?

And no, I won't release an OpenSSH package which differs from the
vanilla sources, unless it's really really necessary to get it working
on Cygwin.  If the performance is a problem for you, build your own
package.  You should have enough details now to get this done.

That's totally understandable but I'd be willing to try and get any patches needed to fix this into the openssh code base, that's not saying I'd be successful but its worth a try.

I've looked for other buffers which may be causing the problem but
cant see anything obvious that I haven't tried yet i.e. the 16K buffers.
Any more ideas would be gratefully received.

It's my understanding that unlike the hpn changes these have little
security impact and hence should be acceptable core changes to
the openssh group.


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]