Peter W. Osel wrote:
> Hello,
> I know that this has been asked before, just wanted to mention that I,
> too, would like to see the HPN SSH functionality incorporated in the
> standard OpenSSH.

As the developer of the HPN-SSH patch I'd like to say that for *most*
people the new version of OpenSSH will probably meet most of their
needs. The developers increased in the internal window size to 2MB
(which from what I can tell leads to a 1MB effective size in BDP
equations). This *significantly* increases performance over the previous

However, for people on faster networks this is still a bit small and
HPN-SSH still has a role there (ex. On a patch between Switzerland and
the US OpenSSH4.6 peaked at 0.69MB/s, OpenSSH peaked at 17.7MB/s and
HPN-SSH at 58.3 MB/s(though it was CPU bound at this point))

> Would there be technical disadvantages integrating the changes?

Initially there were performance problems with LAN transfers between two
HPN enabled hosts. I think the latest version of the code (hpn12v19) has
dealt with that. The larger issue is that for the majority of users -
who tend to be poorly connected - the patch is probably overkill. That
and the integration of the NONE cipher switch likely makes it dead in
the water.

Also, the HPN patch code is a bit of a moving target at this point.
HPN13 is undergoing testing now and represents a more fundamental
departure from the code base than even HPN12 did. I believe we've
reached the limit of what buffer tuning can provide and we've been
exploring other directions for optimization. Hopefully we'll have
something available for a public test by January.

> I know we are all pretty busy, but I would certainly spend time to help,
> e.g. with testing, documentation, etc.

I'll be continuing development on the HPN patch for sometime. I've
brought on a couple more people. We have some interesting plans for the
next couple of years but I believe, and I think the OpenSSH developers
agree with me on this, that there probably won't be a wholesale
integration in the foreseeable future. Honestly, this is likely for the
best. It gives me a bit more freedom to try out different techniques
which the devel team, if they find any of them useful, can integrate
when they can.

Chris Rapier

openssh-unix-dev mailing list