X-Spam-Check-By: sourceware.org Date: Tue, 28 Mar 2006 09:58:40 -0500 (EST) From: Igor Peshansky 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: Message-ID: 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: List-Subscribe: List-Archive: List-Post: List-Help: , 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, 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 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/