This is the mail archive of the
mailing list for the Cygwin project.
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). :-)
|\ _,,,---,,_ email@example.com | firstname.lastname@example.org
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