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.