rsh

Robert G. Brown rgb at phy.duke.edu
Tue Sep 23 22:41:44 EDT 2003


On Tue, 23 Sep 2003, Trent Piepho wrote:

> On Tue, 23 Sep 2003, Robert G. Brown wrote:
> > 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.
> 
> time for i in `seq 1 10` ; do rsh venturi4 echo ; done
> real    0m0.320s
> user    0m0.000s
> sys     0m0.050s
> 
> time for i in `seq 1 10` ; do ssh venturi4 echo ; done
> real    0m4.014s
> user    0m0.820s
> sys     0m0.030s
> 
> About one order of magnitude slower, and a great deal more cpu time.

But still pretty much negligible, on a job intended to run all day.

> But that's not the problem I have with ssh vs rsh, it's copying large files.
> 
> Just last week I needed to copy 65GB of data from an ext3 formatted IDE
> harddrive someone brought in.  The only linux system that I could bring down
> to stick the drive in was my VIA-C3 based thin-client.  Using scp to copy the
> files would have taken all day.  If I could just turn off the stream
> encryption when I don't need it, everything would be fine.  Too bad the
> security-nazis removed that option.

That's fair enough.  Once upon a time you could, and I agree that the
option should still exist.  I once upon a time looked briefly at the ssh
source to see if it was easy to short-circuit, but the sources are
fairly involved and complicated and I couldn't see any easy place to
insert a null function call (without spending a lot more time than it
would save).

After all, a dummy user probably won't know enough to read the man page
anyway and select no encryption (especially if you make it an argument
that HAS to be entered as a command line option).  Anybody smart enough
to read it ought to be smart enough to figure out when to use it.  And
they can even leave in all the encrypted handshaking and authentication
required to establish the connection (which is actually a big chunk of
the time you measure IIRC -- the encryption is relatively fast) and then
just transfer the data quickly.

I suppose in the case of the 65 GB of data you could just NFS export,
mount, and copy (depending on just how thin the client was).  NFS isn't
lightning fast, but one can move data through it at a respectable rate
(less than all day).  And yeah, enabling rsh/rcp long enough to
facilitate the transfer might be easier/faster.

   rgb

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

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