Re: Doc bug? relative speed of inline/out-of-band methods
On 18 Dec 2000, Daniel Pittman wrote: OTOH, IIRC (and several other conditionals), the inline methods hold the entire encoded file in memory, then decode, don't they? Right. If so, out-of-band methods would cause less memory pressure. That might show higher performance... Hm. Kai Großjohann [EMAIL PROTECTED] writes: 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). :) You are using inline methods because the docs say that out-of-bound methods are faster? Cool. kai -- A large number of young women don't trust men with beards. (BFBS Radio)
Re: Doc bug? relative speed of inline/out-of-band methods
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
Doc bug? relative speed of inline/out-of-band methods
The node `Connection types' says: / |The performance of the external transfer methods is generally better | than that of the inline methods. This is caused by the need to encode | and decode the data when transferring inline. | |The one exception to this rule are the `scp' based transfer methods. | While these methods do see better performance when actually | transferring files, the overhead of the cryptographic negotiation at | startup may drown out the improvement in file transfer times. \ 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. Another issue is that inline methods might be slow on XEmacs due to the pty performance bug. Does that bug still exist? 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. I wonder if this documentation might need changing because the inline methods might have gotten too bad a treatment. kai -- A large number of young women don't trust men with beards. (BFBS Radio)