High Performance SSH/SCP - HPN-SSH when?

[Corinna Vinschen]

On Apr  4 16:52, Chris Rapier wrote:
> Corinna Vinschen wrote:
> > On Mar 25 23:37, Chris Rapier wrote:
> >> [http://www.psc.edu/networking/projects/hpn-ssh/]
> >> Development is on going and new version of the patch will be available 
> >> shortly. This new version of the patch will hopefully address a 
> >> performance issue in LAN transfers.
> > 
> > Not sure if it's ok to discuss this here. However, we have some
> > performance problems on Cygwin with the vanilla version of OpenSSH.  The
> > main problem is the size of the read buffers in the client loop, resp.
> > client_process_net_input/client_process_input.  The buffer size is a
> > fixed 8K.  For some reason this degrades performance on Windows
> > enormously, when a copy is made from a remote machine to the local
> > machine, like this:
> 
> I'm guessing that this is probably an issue in the implementation of 
> cygwin. Following the code I would again guess that its probably the 
> memcpy in buffer_append doing it. Perhaps many small memcpy's being more 
> expensive than a few larger ones in the cygwin environment? Is there 
> some sort of trace functionality under cygwin?

memcpy and memmove are optimized handcoded assembler functions, so I
don't think they are the culprit.  Unfortunaltely, the trace
functionality in Cygwin doesn't cover these functions.

> > I also tried the HPN patch, but it doesn't help for this specific
> > situation.  The HPN patch does not touch the application's read buffer
> > size and it turns out that neither changing the underlying SO_RCVBUF
> > buffer sizes nor changing TCP_NODELAY have a really relaxing effect on
> > this situation (less than 10%).  
> > 
> > On the contrary, keeping the application buffers at 8K, the performance
> > even degrades with the HPN patch:
> > 
> >   cygwin> scp linux:file .
> >   file   100%  118MB   1.0MB/s   01:58
> 
> So this is an additional decrease in performance if the HPN patch is 
> used with 8k buffers? What can you tell me about the path? Does it have 
> a very low RTT? The available version of HPN (HPN11) polls the SO_RCVBUF 

The RTT is in the <1ms scale.

> once every window so in low RTT environments the additional cycles spent 
> on this could have an impact. The beta version of the patch (HPN12) 
> provides a switch to disabled buffer polling. I'm still working on this 
> issue (recreating the problems consistently has been an issue for me) 
> but you might want to look at the HPN12 patch set.

I won't have time to test extensively until next week.  But I'll come
back to this.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat