[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: transition RedHat-Debian



On Wed, Sep 14, 2005 at 02:35:41PM +0900, Adam C Powell IV wrote:
> 
> We've been over this a few times on this list before; some argued a
> performance hit with ssh, others seem to think the hit is relatively
> small.  I personally use rsh on all of my group's clusters, noticed a
> huge hit at startup with ssh but haven't characterized the long-term
> impact.  But these clusters are all firewalled, and so have never had
> any problem (that I know of).  This would of course be foolish on
> net-exposed machines, unless you only allow rsh access to localhost.

Just to add a concurring note, on our cluster I run the backups and several
other bulk transfers using rsh rather than ssh.  The maximum speed with ssh
on our machines (starting to age now) is around 150 Mbps, pegging a CPU at
each end.  With rsh it's ~650 Mbps and isn't using most of a CPU.  Startup
delay for ssh is also a lot higher (qualitatively, I notice ssh startup
times but not rsh startup times).  NFS is higher still, but only if you're
doing large files or multithreaded.  For small files tar/rsync/... over rsh
is faster.

If you're using MPI, PVM, or NFS between nodes, you're sending data and
control (potentially even process forks) in the clear without
authentication, so you're already trusting your network.  Using rsh doesn't
require any more trust.  You do need to make sure it's not exposed outside
your trusted network though (just like MPI, PVM, NFS), so if you don't need
bulk data performance or fast startups, there's no reason to install a real
rsh.  I'd stick to ssh until you determine that ssh is a real bottleneck,
and then be careful at your border machines with the rsh traffic.

I do use ssh in other capacities though: passwordless login to slave nodes
by end-users, X11 forwarding, etc.  The security features aren't the reason
in these cases though, just the convenience.

-Drake



Reply to: