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, Igor Peshansky wrote:

> 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
                                       ^^^^^^^^^^
Umm, make that "stack-allocated".  That'll teach me to re-read my messages
before hitting "Send".

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