RSH scaling problems...

[Jesse Becker]

On Wed, 18 Dec 2002, Robert G. Brown wrote:

> My standard comment is that everyone in the computing universe should
> simply stop using rsh, period, ever, for anything, and start using its
> nextgen replacement ssh instead.

No argument there.

> It is marginally more "expensive" than rsh in system resources and
> latencies associated with making a connection, but we're talking tenths
> of seconds here, from my direct measurements, and that was some years
> ago on slower machines AND included the use of bidirectional traffic
> encryption.  On a sandbox cluster LAN, one can of course NOT use
> encryption in ssh and still realize all its benefits.

It's worth noting two things:
  1)  SSH supports different ciphers
  2)  Different ciphers are faster to compute than others.

I did some testing on a local system, and come up with some times for 
transfering a file via SSH using various ciphers.  The file in question 
was generated via this command (which generated 525 megs of data):  
   dd if=/dev/urandom of=./stuff bs=1M count=500

I used all of the ciphers below, repeated each test 10 times, and recorded 
the results.  The systems were otherwise unused.  Both boxes are dual Xeon
2.4GHz boxes, 2GB of RAM, and a single UATA 40GB IBM Deskstar 120GXP 
drive.  Both systems run Redhat 7.3, with 2.4.18-5 smp kernels.  There is 
an Intel 1000/PRO 82544GC Gigabit NIC in each box (using the eepro100.c: 
$Revision: 1.36 $ modules), and the switch is (IIRC) a Netgear GS516T 16 
port gigabit switch.

Both boxes use the latest offical release of OpenSSH 3.1p1 from Redhat.

   Cipher             Transfer time (sec)         Avg.(sec)   Rate
-------------   -----------------------------     ----        ----
aes128-cbc:     20 18 21 20 21 20 18 20 20 19 ==> 19.7        26.6
aes192-cbc:     22 21 22 22 22 21 22 21 19 20 ==> 21.2        24.7
aes256-cbc:     23 23 22 24 23 23 23 22 23 23 ==> 22.9        22.9
blowfish-cbc:   19 18 19 17 16 19 16 17 18 19 ==> 17.8        29.4
cast128-cbc:    18 20 20 18 19 20 20 20 20 20 ==> 19.5        26.9
arcfour:        19 19 19 17 19 18 16 19 18 18 ==> 18.2        28.8
3des-cbc:       44 46 45 45 46 44 45 43 45 45 ==> 44.8        11.7

I can rerun the test with a 2GB file (to ensure that nothing gets cached) 
if people are interested.

Times for the same test using a 2.1GB file:
   Cipher         Trans time (sec)     Avg.(sec)  Rate
-------------   -------------------     ----      ----
aes128-cbc:     81  80  77  74  80  ==> 78.4      27.4
aes192-cbc:     77  80  82  84  79  ==> 80.4      26.7
aes256-cbc:     85  83  90  83  87  ==> 85.6      25.1
blowfish-cbc:   69  70  75  69  70  ==> 70.6      30.4
cast128-cbc:    70  72  76  80  73  ==> 74.2      28.9
arcfour:        64  70  66  71  67  ==> 67.6      31.8
3des-cbc:       170 175 177 172 170 ==> 172.8     12.4

The default order is aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc,
arcfour, aes192-cbc, aes256-cbc, so you should use one of the faster
ciphers if you don't specify anything.

I don't have rsh enabled anywhere, but copying the same files over an NFS
(v3) mount took about 11.7 seconds for 525MB, and 54 seconds for 2.1GB.
These are averages of 5 transfers, and it works out to about 44.8 and 39.8
Mb/sec respectively.

> The only significant bitch that I have with ssh these days is that the
> openssh designers viewed a feature of rsh -- the ability to remotely
> initiate a process and then disconnect, leaving the backgrounded process

Have you tried using screen(1)?  It works very well with SSH, although 
it's not as useful for the "fire-n-forget" method of running things.

--Jesse