Message-ID: <04e501c65297$7b4979b0$b3db87d4@multiplay.co.uk>
From: "Steven Hartland" <killing AT multiplay DOT co DOT uk>
To: <cygwin AT cygwin DOT com>
References: <04b601c651b4$a1e9e020$b3db87d4 AT multiplay DOT co DOT uk> <20060328074041 DOT GJ20907 AT calimero DOT vinschen DOT de> <01f501c65254$796572e0$b3db87d4 AT multiplay DOT co DOT uk> <20060328143952 DOT GN20907 AT calimero DOT vinschen DOT de>
Subject: Re: very poor cygwin scp performance in some situations
Date: Tue, 28 Mar 2006 19:43:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; 	format=flowed; 	charset="iso-8859-1"; 	reply-type=original
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

----- 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.

    Regards
    Steve


================================================
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 postmaster AT multiplay DOT co DOT uk.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/