HPN-SSH: High Performance ssh and scp(psc.edu)
psc.edu
HPN-SSH: High Performance ssh and scp
http://www.psc.edu/index.php/hpn-ssh
13 comments
Did you mean "brew install --with-hpn openssh"?
This is buggy. We had it deployed on a small number of servers , basically our backup server and a few servers that needed to backup to the backup server.
We would run into problems with standard SSH connecting to HPN-SSH these bugs were confusing and difficult to debug until we realized that the difference was HPN-SSH and reverted to standard SSH all problems went away quite quickly.
We would run into problems with standard SSH connecting to HPN-SSH these bugs were confusing and difficult to debug until we realized that the difference was HPN-SSH and reverted to standard SSH all problems went away quite quickly.
Could you tell me what sort of problems you were experiencing? I'm more than happy to take bug reports at [email protected].
What is the license of these patches? There doesn’t seem to be anything on the website, nor in all of the patches available for download.
Are there other reasons apart from licensing why this has not been merged into mainline OpenSSH?
Edit: At least the multithreaded AES-CTR cipher has license information in the header, which seems to be standard BSD. It stands to reason that the rest of the patches have the same license?
Are there other reasons apart from licensing why this has not been merged into mainline OpenSSH?
Edit: At least the multithreaded AES-CTR cipher has license information in the header, which seems to be standard BSD. It stands to reason that the rest of the patches have the same license?
The Sourceforge page says the project is BSD-licensed. But if the license isn't applied to all the files, and no other root-directory file says that all the files contained within are licensed as such, i'm pretty sure you're not legally covered. If I were a distro I wouldn't include these without asking the authors to put a license declaration covering all the patch changes at the beginning of the file.
I am the author. Honestly, I initially released them without any sort of license - entirely free from any sort of license restriction. People don't seem to understand that so I said they have a BSD license on them. Personally, the license is kind of a moot point (in my view) as the once you patch OpenSSH with them the code is subsumed by the license used by OpenSSH. The only but that might be up in the air is the aes-ctr cipher. In any case I'm trying to find the cycles to include the license and then incorporate it into all of the bits and then build new packages for sourceforge. In the mean time, take my word (as the author) regarding the license. It's free and open. Just keep the attribution. Send me mail at [email protected] for identity confirmation if you like.
I wrote an email to the HPC-SSH team and got the following response:
> I'm at a conference this week so I'll make the license more clear next week in the repo. Basically, it's a very lax bsd style license. Maintain attribution and you can do as you like with it. However, please understand that when incorporated into OpenSSH the OpenSSH license takes precedence.
> Also out had been submitted some years ago but there was resistance to the patch for non technical reasons so I've home my own way on it.
> Chris
> I'm at a conference this week so I'll make the license more clear next week in the repo. Basically, it's a very lax bsd style license. Maintain attribution and you can do as you like with it. However, please understand that when incorporated into OpenSSH the OpenSSH license takes precedence.
> Also out had been submitted some years ago but there was resistance to the patch for non technical reasons so I've home my own way on it.
> Chris
I'm not sure about that.
I think that it was merged into FreeBSD a while back though: http://svnweb.freebsd.org/base?view=revision&revision=224638
I think that it was merged into FreeBSD a while back though: http://svnweb.freebsd.org/base?view=revision&revision=224638
Why isn't this merged upstream, I wonder? Here's a thread I found for Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693424
There's an Ubuntu PPA: https://launchpad.net/~w-rouesnel/+archive/ubuntu/openssh-hp...
And an Arch Linux AUR: https://aur.archlinux.org/packages/openssh-hpn/
ESNet has a good website for high-performance data transfers: http://fasterdata.es.net
In addition to host and network tuning guides they also have a list of data transfer tools, including HPN-patched sftp and scp, but they recommend GridFTP because it supports parallel streams: http://fasterdata.es.net/data-transfer-tools/gridftp/
In addition to host and network tuning guides they also have a list of data transfer tools, including HPN-patched sftp and scp, but they recommend GridFTP because it supports parallel streams: http://fasterdata.es.net/data-transfer-tools/gridftp/
I've been using this a lot recently - https://github.com/LabAdvComp/UDR - A UDT wrapper around rsync - No need to patch anything, therefore no maintenance woe
After finding that using scp to copy stuff over my local network (and before finding out about hpn-ssh) I wrote this icky script to get better performance copying moving stuff around: https://github.com/toofar/fcp
It just wraps ssh+netcat+tar. The ssh connection is just used to setup the netcat (actually nc) connection like in mosh.
It doesn't have much dependencies (although it can use pv if installed on the local machine) and so should work on most platforms (didn't work on android last I checked, but I think I know why). It's a pretty ugly script (in particular errors are not propagated back to the terminal and backgrounding pv can lead to offset output) but it works and can even use scp's bash_completion script for completion on a remote filesystem.
It just wraps ssh+netcat+tar. The ssh connection is just used to setup the netcat (actually nc) connection like in mosh.
It doesn't have much dependencies (although it can use pv if installed on the local machine) and so should work on most platforms (didn't work on android last I checked, but I think I know why). It's a pretty ugly script (in particular errors are not propagated back to the terminal and backgrounding pv can lead to offset output) but it works and can even use scp's bash_completion script for completion on a remote filesystem.
no need of netcat: tar c . | ssh user@host tar x -C destdir
The need to use netcat is that it is faster. It gets better throughput in the presence of plentiful bandwidth. The whole point was to avoid using ssh for bulk transport.
ssh user@host "nc -l 1234 | tar x -C dest_dir"
and in another terminal:
tar c . | nc -p host 1234
If you do not care about security, why not using rcp ?
and in another terminal:
tar c . | nc -p host 1234
If you do not care about security, why not using rcp ?
Gentoo has this as a USE flag for openssh and is enabled by default. Be aware that the multithreaded AES-CTR patch has compatibility conflicts with some libssh versions and possibly other implementations. XBMC and Synology in particular have both been unable to connect to servers using that patch.
Honestly, I'm not aware of these connection problems. If you have any further information please send it to [email protected].
I wonder what the current performance difference is to OpenSSH6.1+? I think those graphs they have might be very old, and there's been a lot of improvements in the core OpenSSH code since then.
Native OpenSSH performance seems quite good these days- are you certain this is still necessary? Either the SSH client and server I used had this patch, or the windowing code in SSH was removed/modified.
The main problem is that the internal buffer size for OpenSSH is limited to 2MB (actually it's closer to 1.25MB in real world terms). This is pretty good for a lot of home users. However, HPN-SSH was written for the HPC communuity where we have have BDPs of well more than that (8MB is not uncommon). So if you have a BDP of more than 2MB HPN-SSH is still going to be a win for you.
2 questions:
1) would this work with mosh? 2) lzo/lz4 has lower latency then zip, is there an ssh patch supporting this and would it be noticable in a 2k4 scenario?
I don't think mosh-type scenarios are what HPN-SSH aims to improve. It is more targeted at high-bandwidth, high-latency scp transfers.
(say, 300Mb+ connections with 30ms+ latency)
(say, 300Mb+ connections with 30ms+ latency)
mosh uses a completely different protocol (over UDP), and I think the aim of these patches is to improve throughput, not latency, of SSH. In a high performance situation you probably have high bandwidth, and then it's better to disable any compression. Compression only makes sense when you have limited bandwidth and sufficient CPU power.
I'm drooling over this. Will this ever show up in RedHat?
Not likely. The OpenSSH team is very conservative, and RedHat isn't likely to make such an invasive change into a core utility.
PSC has been maintaining these patches for a long time. I'm pretty sure I was using this nearly 10 years ago. If you have a need for this, it's not hard to build it yourself.
Ah, found the initial release date: July 7, 2004; yeah 10 years.
PSC has been maintaining these patches for a long time. I'm pretty sure I was using this nearly 10 years ago. If you have a need for this, it's not hard to build it yourself.
Ah, found the initial release date: July 7, 2004; yeah 10 years.
check out bbcp if you are interested as well.
Do you mean bbftp?
http://www.nas.nasa.gov/hecc/support/kb/bbftp_147.html
http://www.nas.nasa.gov/hecc/support/kb/bbftp_147.html
I'm guessing they meant this:
* http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm
* http://www.slac.stanford.edu/~abh/bbcp/
* http://www.slac.stanford.edu/~abh/bbcp/bin/
I've not tried it, though.
* http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm
* http://www.slac.stanford.edu/~abh/bbcp/
* http://www.slac.stanford.edu/~abh/bbcp/bin/
I've not tried it, though.
Or, once the PR https://github.com/Homebrew/homebrew-dupes/pull/358 is merged,
EDIT: fix, thanks dkubb