HPN Patch for OpenSSH 4.2p1 Available

[Michael A Stevens]

I would suspect those performance decreases are more of a CPU issue, as 
the platforms you named are relatively low performance. The issue I ran 
into when designing this was how often to poll the Operating System for 
an update of the window size. I'm not sure what the correct answer is, as 
this is a relatively stupid metric for forcing a syscall every window_size 
bytes. Ideally we would just be notified of changes to the TCP window 
maximum.

Mike

On Sun, 9 Oct 2005, Darren Tucker wrote:

> 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.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>