X-Spam-Check-By: sourceware.org
Date: Tue, 28 Mar 2006 09:57:33 -0500 (EST)
From: Igor Peshansky <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Subject: Re: very poor cygwin scp performance in some situations
In-Reply-To: <20060328143952.GN20907@calimero.vinschen.de>
Message-ID: <Pine.GSO.4.63.0603280951550.18642@access1.cims.nyu.edu>
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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Tue, 28 Mar 2006, Corinna Vinschen wrote:

> 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 wonder...  The buffer is currently statically allocated.  Would there be
negative impact if it were malloc()ed?  In this case, the size could be
controllable via a command-line option, which would allow tuning this
locally without recompiling openssh.

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

Ditto on this one (in fact, this could be controlled by the same
command-line option).  FWIW, this sounds to me like a Cygwin- (or, rather,
Windows-) specific issue.

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

As you said, this one doesn't have all that much impact, and thus isn't
worth patching openssh for (though again, adding a command-line option
would probably make sense, since it's unlikely that option processing
will have much effect on performance).

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

All of the above will probably need to be suggested to the OpenSSH team
(preferably in the form of patches).  Volunteers welcome (nudge-nudge,
wink-wink, Steve). :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha AT cs DOT nyu DOT edu | igor AT watson DOT ibm DOT com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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