[Colin Watson] > Sorry, but I am not going to include any more large and invasive patch > sets in Debian's OpenSSH package, especially not ones that add new > configuration options (upstream has a history of giving such things > different names when they accept them, and then I'm stuck maintaining > configuration file compatibility forever). This needs to go upstream.
Understandable, but too bad. Apparently this dramatic performance improvement is unlikely to go upstream: "So if HPN-SSH is so awesome why hasn't OpenSSH adopted it? That's a long story and people who know the OpenBSD team probably already know the answer. I understand many of their reasons - it's a big patch which would require additional work on their end (and they are a small team), they don't care as much about performance as security (though there is no security implications to HPN-SSH), etc etc etc. However, even though OpenSSH doesn't use HPN-SSH Facebook does. So do Google, Yahoo, Apple, most ever large research data center, NASA, NOAA, the government, the military, and most financial institutions. It's pretty well vetted at this point." - http://stackoverflow.com/questions/8849240 My own 2c: the NONE cipher and the parallel AES implementation are not very interesting, because with an Intel Sandy Bridge CPU (with hardware acceleration for both AES and GCM), the AES + GCM mode ciphers are _really_ fast. Anyone who cares about performance should be using them, and should buy Sandy Bridge or newer CPUs. But the receive buffer scaling part of the HPN patchset is still relevant, and in fact quite critical for long fat pipes. (Fortunately the various features are broken out into individual patches.) I wonder how long until OpenSSH upstream realises that a 1.2 MB window is not really large enough on today's Internet.