New HPN Patch Released

Chris Rapier rapier at
Sat May 20 07:33:52 EST 2006

The HPN12 patch available from addresses performance 
issues with bulk data transfer over high bandwidth delay paths. By 
adjusting internal flow control buffers to better fit the outstanding 
data capacity of the path significant improvements in bulk data 
throughput performance are achieved.

In other words, transfers over the internet are a lot faster with this 
patch. Increase in performance of more than an order of magnitude are 
pretty common. If you make use of the now included NONE cipher I've hit 
data rates of more than 800Mbps between Pittsburgh and Chicago and 
650Mbps between Pittsburgh and San Diego. The NONE cipher is only used 
during the bulk data transfer and *not* during authentication. This 
version of the patch makes the NONE cipher a server side configuration 
option so you don't have to enable it if you don't want to.

Command line switches have been abandoned in favor of configuration 
options which are outlined below and in the HPN12-README included in the 

Other versions of the patch showed some performance decrease in local 
area network transfers. I've addressed this by changing the size of one 
of the buffers (thanks Darren) and giving people the option of turning 
off HPN functionality. I've done my best to verify this by running 
several thousand tests and analyzing the results. These results are 
available from
However, there is always the chance that new problems have been 
introduced that didn't show up in my environment. So while I am 
reasonably confident there are no problems with this patch use al 
appropriate caution especially in production environments.

Configuration options for HPN:
TcpRcvBuf=[int] (KB) client
       set the TCP socket receive buffer to n Kilobytes. It can be set 
up to the maximum socket size allowed by the system. This is useful in 
situations where the tcp receive window is set low but the maximum 
buffer size is set higher (as is typical). This works on a per TCP 
connection basis. You can also use this to artificially limit the 
transfer rate of the connection. In these cases the throughput will be 
no more than n/RTT. The minimum buffer size is 1KB. Default is the 
current system wide tcp receive buffer size.

TcpRcvBufPoll=[yes/no] client/server
       enable of disable the polling of the tcp receive buffer through 
the life of the connection. You would want to make sure that this option 
is enabled for systems making use of autotuning kernels (linux 2.4.24+, 
2.6, MS Vista) default is no.

NoneEnabled=[yes/no] client/server
       enable or disable the use of the None cipher. Care must always be 
used when enabling this as it will allow users to send data in the 
clear. However, it is important to note that authentication information 
remains encrypted even if this option is enabled. Set to no by default.

NoneSwitch=[yes/no] client
       Switch the encryption cipher being used to the None cipher after
authentication takes place. NoneEnabled must be enabled on both the 
client and server side of the connection. The connection attempt will 
fail with an error if a client requests a NoneSwitch from the server 
that does not explicitly have NoneEnabled set to yes. Set to no by default.

HPNDisabled=[yes/no] client/server
      In some situations, such as transfers on a local area network, the 
impact of the HPN code produces a net decrease in performance. In these 
cases it is helpful to disable the HPN functionality. By default 
HPNDisabled is set to no.

HPNBufferSize=[int] (KB) client/server
      This is the default buffer size the HPN functionality uses when 
interacting with nonHPN SSH installations. Conceptually this is similar 
to the TcpRcvBuf option as applied to the internal SSH flow control. 
This value can range from 1KB to 14MB (1-14336). Use of oversized or 
undersized buffers can cause performance problems depending on the 
length of the network path. The default size of this buffer is 2MB. 
TcpRcvBufPoll, if set to yes, will override this value. This behaviour 
may change in future versions.

Comments, questions, and especially critiques are always welcome.
Note: I did not attach the patch, as is customary, because its around 
1900 lines.

Chris Rapier
Network Research & Application Engineer
Pittsburgh Supercomputing Center

More information about the openssh-unix-dev mailing list