automating commands on nodes
Robert G. Brown
rgb at phy.duke.edu
Tue Jun 6 13:18:50 PDT 2000
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.
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
More information about the Beowulf