🚀 go-pugleaf

In article <KARL.92Sep14005723@crappie.MorningStar.Com>, karl@MorningStar.Com (Karl Fox) writes:
> In article <laq57rINN34i@jethro.Corp.Sun.COM> Eric.Arnold@Sun.COM
> (Eric arnold) writes:
> 
>    With PPP, I've noticed that "rsh" ( E.g. 
>    "rsh remotehost 'cat <filename' >filename", or whatever -- as long as
>    it is a byte stream) is about twice as fast as "ftp" and "rcp".  Is
>    there a way around this?  "rcp" and "ftp" are nice facilities,
>    especially with wrappers like "ftptool".
> 
> I don't get quite the same results, but I do see a small but
> significant speed advantage of rsh and ftp over rcp.  I turned up
> debugging (I'm using Morning Star PPP, as you might guess :-), and
> noticed that rsh and ftp send full size frames (1500 bytes), but rcp
> sends 552-byte packets (552=20+20+512).  Both sizes are before Van
> Jacobson TCP header compression.
> --
> Karl Fox, Morning Star Technologies                            +1 800 558 7827
> 1760 Zollinger Road, Columbus, Ohio 43221                      +1 614 451 1883


I doubt you are comparing apples to apples.  The MSS is not commonly,
at least as far as I know, directly affected or even changable by
the application.

Could your rcp target be more distant?  Causing the familiar
(Host Requirements and elsewhere) mechanisms to pick a maximum segment
size of <= 512?

Of course, `rcp` is implemented with `rsh`.  The local rcp command
does the moral equivalent of `rsh remotehost rcp ...`.  That is the source
of the ever popular "protocol screwup" error message cause by babbling
from the .cshrc on the remote machine.


Vernon Schryver,  vjs@sgi.com