On Sun, Oct 30, 2005 at 02:41:25PM +0100, frantisek holop wrote: > hi there, > > poking around in the HP ssh docs, one can see the following in the FAQ: > > Q: How is the performance of HP-UX Secure Shell? > A: Compared with conventional file transfer methods, the scp command > is 2 - 3 times slower than rcp, and sftp is 2 to 3 times slower than > ftp. This is because HP-UX Secure Shell authenticates both the server > and users, and encrypts both the data and the password. In addition, > HP recommends you use the /dev/random device on your system to > significantly speed up program initialization. > > i find it interesting that most of the user community perceives > scp/sftp multiple times slower then their not encrypted counterparts. > > now, not taking into consideration the HP-UX itself is a bottleneck > on its own (not mentioning their RNG interface) i think some of us
prngd also helps if you can't get a real /dev/random for your system, or can't afford downtime to install the device driver. > agrees that scp/sftp is "kind of slower" when it comes to bulk data > transfer. nobody expects scp to be as fast as samba or ftp of course, > the encryption has a great overhead, especially for older machines > (which my local network router is) Selecting a fast cipher/mac pair can make a significant difference. Of the standard ones, arcfour and hmac-md5-96 are usually fastest. > but a couple of months ago a link appeared here describing a HPN > (as in hihg performance enabled) ssh patch. i kept that mail for > a very long time because i was very much interested in the answers > of the ssh developers, but there was none. and so i assumed it must > be rubish or something. It's not rubbish, but it only helps in certain situations (ie when you have a "long, fat pipe"). The breakpoint is when the amount of data in the pipe gets to about 64kb, which is a RTT of about 5ms on a 100Mb/s network or 50ms on a 10Mb/s one. > so before anyone tags this mail as a trolling flamebait > (which it is not), i just would like to ask > -have others tried HPN-SSH? > -have ssh developers tried it? I have. The current one has a couple of problems: the main one being that it is slower in situations where you have more bandwidth than CPU (10% to 25% in my experiments) and uses more CPU and memory under most conditions. There's no fundamental reason why this should be so since you're not doing any more work, just making better use of the available bandwidth. It also has a few stylistic issues (duplicated code inline rather than in its own function, some slightly convoluted logic, unnecessary changes in scp and use of sizeof(somebuffer) for read limits where the somebuffer is unrelated but just happens to be the right size). I've proposed some changes to address these, but since I don't have a suitable link to test it on (and attempts to simulate one have given inconsistent results) I can't tell if my changes still work as expected. The PSC folks were going to test them but that was a few weeks ago and I've not heard from them since. Most of the discusstion was over on the openssh list. Code review with some proposed changes: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=112316226728255 Thread on performance issues: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=112884429502318 The patch attempting to address this is not in the thread: http://bugzilla.mindrot.org/attachment.cgi?id=1013 > i think it would be very nice to have a performance page on the openssh > site describing what should be expected, what is "normal" and the > intended performance of ssh to clear up possible misunderstandings. > (like mine here) http://www.openssh.com/faq.html#3.3 covers authentication times but not throughput. -- 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.
