New HPN Patch Released
Chris Rapier
rapier at psc.edu
Sat May 20 07:33:52 EST 2006
The HPN12 patch available from
http://www.psc.edu/networking/projects/hpn-ssh 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
patch.
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 http://www.psc.edu/networking/projects/hpn-ssh/results.html
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