HPN Patch for OpenSSH 4.2p1 Available

[Darren Tucker]

Chris Rapier wrote:
> As a note, we now have HPN patch for OpenSSH 4.2 at 
> http://www.psc.edu/networking/projects/hpn-ssh/
> 
> Its still part of the last set of patches (HPN11) so there aren't any 
> additional changes in the code. It patches, configures, compiles, and 
> passes make tests without a problem. I've not done extensive testing for 
> this version of openssh but I don't foresee any problems.
> 
> I did run a couple tests between two patched 4.2 installs (one in 
> switzerland, the other in pennsylvania, usa) and hit around 12MB/s with 
> the hpn patch and 500KB/s with the standard install. So it still seems 
> to work as expected.

Have you done any analysis of the impact of the patch on low-latency/BDP 
links (ie LANs)?

I've been doing some work with parts of the HPN patch.  For scp'ing to 
and from localhost and LANs (see below), the scp changes on their own 
(actually, a variant thereof) shows a modest improvement of 2-3% in 
throughput.  That's good.

For the entire patch (hpn11), however, it shows a significant *decrease* 
in throughput for the same tests: 10% slower on OpenBSD to localhost, 
12% slower on Linux to localhost and 18% slower Linux to OpenBSD via a 
100Mb/s LAN).  That's bad.  I would imagine LANs are more common than 
high BDP networks that your patch targets :-)

scp to localhost, OpenBSD 3.8-current, 733MHz P3/Celeron)
	-current	-hpn11
real    2m40.966s	2m57.296s	(10.2% slower)
user    0m33.187s	0m45.820s
sys     0m31.500s	0m37.539s

scp to localhost, Fedora Core 3, 933MHz VIA CPU)
	-current	-hpn11
real    3m19.578s	3m43.944s	(12.2% slower)
user    0m0.086s	0m0.082s
sys     0m11.202s	0m12.152s

scp FC3 to OpenBSD 3.8, 100Mb/s switched LAN, no stack tuning:
	-current	-hpn11
real    1m59.486s	2m22.000s	(18.8% slower)
user    1m6.839s	1m18.344s
sys     0m43.040s	0m43.004s

I suspect that the buffer size increases you do are counterproductive 
for such networks.  I also suspect that you could get the same 
performance improvements on high-BDP links as you currently do by simply 
increasing the channel advertisements without the SSH buffer changes and 
relying on the TCP socket buffer for output and decrypting quickly for 
input but I'm not able to test that.

Test method, with a 64MB file:
$ time for i in 1 2 3 4 5 6 7 8 9 0; do scp -ocompression=no -o 
ciphers=arcfour /tmp/tmp localhost:/dev/null; done

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.