Kai Großjohann <[EMAIL PROTECTED]> writes:
[...]
> Michael Kifer claims that `scp' might be slower than inline methods
> due to the cryptographic overhead involved while transferring the
> file. (This is distinct from the startup overhead; it refers to what
> happens after startup: encryption and decryption.) Hm. OTOH, the stuff
> that goes through the shell connection is also encrypted.
The real slowness is the cryptographic validation during connection
startup. ssh(1) costs when you first connect. scp(1) also costs when you
first connect.
The real difference is that you pay that startup for *every* file open
with scp(1), but only once with ssh(1) and inline transfer.
> Another issue is that inline methods might be slow on XEmacs due to
> the pty performance bug. Does that bug still exist?
Yes. I have it on my todo list to look into, but it's not likely to be
real soon now, I fear.
> Does anybody have figures for the relative speed? I use inline methods
> because they feel faster, even for fairly large files such as my
> site-start.el. But I have no objective data.
scp(1) and inline ssh(1) transfers both run at ~ 300 KB/s on my P-II 400
with a cheap NE2000 PCMCIA NIC (limit of ~1.05 MB/s).
I have not made exact timings, but on anything less compute bound than
my system (which is :), you *might* see scp(1) peak in transfer speed...
OTOH, IIRC (and several other conditionals), the inline methods hold the
entire encoded file in memory, then decode, don't they?
If so, out-of-band methods would cause less memory pressure. That might
show higher performance...
> I wonder if this documentation might need changing because the inline
> methods might have gotten too bad a treatment.
I don't think so. It matches my experimental evidence, and is why I use
inline rather than OOB methods myself - after being a long-time user of
OOB scp(1). :)
Daniel
--
An idea that is not dangerous is unworthy to be called an idea at all.
-- Elbert Hubbard
