automating commands on nodes

[Robert G. Brown]

On Tue, 6 Jun 2000, Victor Ortega wrote:

> On Tue, 6 Jun 2000, Robert G. Brown wrote:
> > I agree, although my measurements (published last week on the list) do
> > show that the bulk of the "cost" of ssh relative to rsh comes from the
> > original RSA handshake, not from the encryption.
> 
> But I believe that your benchmarks were done with copying small files;

Big ones too.  I tested a 1M file copy at 0.67 sec for ssh (using
default idea encryption) vs 0.2 sec for rsh.  I also tested e.g.
blowfish and one can interpolate a bit and still get encryption.  All
this also depends strongly on the speed of the CPUs.  A rough estimate
of 1 (extra) second for each 2 MB sent is probably not unreasonable,
although you might get 3 MB in a second on a good day or even four or
five with blowfish.  Beyond that you're approaching wirespeed.

> I am worried that forwarding a full X connection, encrypted, over ssh
> from some internal node (ssh into head node, ssh into some internal
> node, load up some big GUI) will incur a big performance penalty.  I
> tried this yesterday with a simple two-hop connection, and the GUI was
> twice as slow (it was slow enough already with just a single encrypted
> X connection going over our external 10base-T network).  Unfortunately
> I have no benchmarks for this.

Hmm, hadn't thought about this, as I try not to run graphics-heavy X
apps over any kind of shell connection -- with linux one can usually run
them locally -- although e.g. xterms and simple Tk-ish apps work fine.
I'll have to see if I can set this up to measure it.  However, at an
extra 0.5 seconds per megabyte, I agree that you won't want to play a
hi-res video game this way and that netscape should be significantly
delayed.  "Simple" X apps, though (e.g.  xterm) should be ok, and I
can't think of why one would need to run e.g.  netscape on a node.

I also have no idea if a double ssh doubles this overhead.  It might be
that a->b is encrypted and then b->c is REencrypted.  Or it might be
that the b->c transfer forwards the keys (so to speak).  I'll try to
test this as well.

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu