ssh speed

[Rob Hagopian]

These were using SNAP-010109 on PIII 800s, striped 10K RPM drives,
switched fast ethernet. One machine is SMP, one isn't. Using 'scp -o
Ciphers=xxx' Both machines are FreeBSD.

(587MB file:)
aes256-cbc	02:19
aes128-cbc	02:17
arcfour		02:08
3des-cbc	02:59
blowfish-cbc	02:13
none2		02:12

I did "hack the source" (hehehe) to add none:

                rijndael_setkey, rijndael_setiv,
                rijndael_cbc_encrypt, rijndael_cbc_decrypt },
+       { "none2",
+               SSH_CIPHER_SSH2, 8, 0,
+               none_setkey, none_setiv,
+               none_crypt, none_crypt },
         { NULL, SSH_CIPHER_ILLEGAL, 0, 0, NULL, NULL, NULL, NULL }
 };

(it's none2 to avoid name collision with the ssh1 none)

Indeed, it seems that when using a cipher, the ssh process is using more
cpu than sshd and is maxing out that side. But when using none2 as a
'cipher' CPU maxes out around 30% for ssh (20% for sshd). Both processes
seem to be in select() a lot according to top.
								-Rob

On Wed, 10 Jan 2001, Markus Friedl wrote:

> On Wed, Jan 10, 2001 at 10:37:35AM +0100, Markus Friedl wrote:
> > did you use compression?
> 
> oops, i should read the all of the mail.
> 
> what did you do? scp? ssh+cat? sftp? http over forwarded
> channels?
> 
> what are exact version of openssh? openssh-current? did you try AES?
> 
> what kind of network? CPU? transfer to localhost?
> 
> did you really use 'none' in SSH-2? did you hack the source (cipher none 
> should not be supported)?
> 
> -markus
> 
> > On Tue, Jan 09, 2001 at 06:28:10PM -0500, Rob Hagopian wrote:
> > > OK, I've been looking to run ssh2 without encryption to get maximum
> > > throughput but with secure authentication. However, my tests show that the
> > > performance speedup isn't as dramatic as I suspected:
> > > 
> > > For a 587MB file:
> > > 3des-cbc	3:03
> > > arcfour		2:10
> > > none		2:13
> > > 
> > > ftp		0:57
> > > 
> > > I checked, compression is off (with it on estimated times were over 5min).
> > > 
> > > I interpret the above as saying that the cipher does make a difference,
> > > but when using a sufficiently fast cipher there's overhead in the protocol
> > > that becomes the bottleneck. Arcfour didn't max out the CPU, nor the disk
> > > or network I/O, so what could be slowing it down? Thoughts? Suggestions?
> > > 
> > > 								-Rob
> > > 
>