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


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@cs.nyu.edu | igor@watson.ibm.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/


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