rsh

Robert G. Brown rgb at phy.duke.edu
Tue Sep 23 20:32:03 EDT 2003


On Mon, 22 Sep 2003, Jan Schaumann wrote:

> Chris Samuel <csamuel at vpac.org> wrote:
>  
> > On Wed, 17 Sep 2003 12:51 pm, masego-otlhe_segone wrote:
> > 
> > > I have managed to install mpich v1.2.5.2 on my cluster of two nodes, but I
> > > just realised that I cannot communicate with other hosts due to some rsh
> > > setting that I need to do.
> > 
> > To be honest I'd really suggest not using RSH and swapping over to OpenSSH 
> > instead.
> 
> Why?  Most likely, ssh will introduce a non-negligible overhead in
> encryption and/or compression.

I'd actually say that it will introduce a negligible overhead in both
those dimensions for most usage.  As in a few seconds (extra) to launch
quite a few tasks.  Periodically I measure and post the numbers but can
never remember what they are the next time this issue rolls around.
However, they aren't horribly large in absolute terms, let alone
relative ones, and are likely to be cumulatively signficant only on very
large clusters for most tasks.

With that said, for some usage patterns (spawning lots of very short
tasks) they might impact signficantly even on small clusters (yes, the
mandatory YMMV:-) , but for the more common spawning of lots of tasks
intended to run >>a signficant amount of time<< (e.g. a day), the
fraction of a second per task marginal cost associated with startup via
ssh vs rsh is indeed negligible.  Even tasks where this isn't the case
can usually be engineered so that it is (and should be).  If ssh isn't
adequately efficient, chances are good that rsh is a (smaller but still
significant) bottleneck too, since the latency differential is only
about a factor of two or three IIRC, and should be scaled away by
altering your task organization so that the parallel task runs a "long"
time compared to startup time for any remote shell.

The issue can also be avoided (as Josip notes) by using LAM or PVM,
which spawn a daemon via ssh but subsequently start tasks without any
shell-level overhead at all.

Overall, given my sysadmin background, I tend to really dislike the idea
of keeping rsh around at all and expect that one day it will be
deprecated and just go away (in many environments this is true already).
It is obsolete, insecure, and fairly stupid when it comes to managing
the shell environment.  ssh has a lot of advantages compared to rsh
aside from its security.  I personally wish they had left in the option
to turn off encryption (AS an option) which one used to be able to do
just to reduce the overhead still further on clusters while retaining
its other advantages and features, but not unreasonably the ssh people
decided not to so that foolish users couldn't turn it off by accident or
design.

In many environments, the time wasted by ONE successful password crack
due to snooping is far, far greater than any number of rsh margins.

   rgb

> 
> To the OP: check your /etc/hosts.equiv and ~/.rhosts, as suggested by
> rsh(1) and rlogin(1).
> 
> -Jan
> 
> 

-- 
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



_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf



More information about the Beowulf mailing list