[Bug 1337] SCP performance twice as slow as RCP

[bugzilla-daemon at bugzilla.mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=1337


Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au




--- Comment #3 from Darren Tucker <dtucker at zip.com.au>  2007-07-13 21:23:52 ---
(In reply to comment #2)
> I had to comment on such a nice bug number :)
> 
> Darren, in relation to your point 4 above, will it help the following?
> I noticed that for scp if you disable compression (yes disable),
> then transfer rate increases a lot. I looked at it very quickly
> and it seemed worse the more the data compressed.

Like many things, the answer is "it depends".  Compression is not free,
and is not automatically a win.  It gets better throughput when the
time taken to compress and decompress the data is less than the amount
of time saved by transferring the smaller amount of data across the
pipe.

If you have a fast CPU, slow link and compressible data, enabling
compression is probably a win.  On the other hand, since TCP
connections to localhost are relatively fast, enabling compression on a
localhost will probably slow things down.  Ditto for enabling
compression on uncompressible data such as your random output: you will
spend a lot of  CPU trying (and failing) to compress the data. 
Enabling it for a localhost copy of compressed data pretty much
guarantees that it will be slower.

> Also Protocol=1 seems much better:
[...]
> #setting Protocol=1 in sshd_config I get the following speed:

You don't need to do that.  Assuming your server has "Protocol 2,1"
then you can switch between the two with "scp -o Protocol 1" (or 2).

> $ scp -C localhost:50MB_zeros /tmp #Includes time to type password!

Including user interaction in the timing adds a potentially large
variation in the results.  Use pubkey authentication for more
consistent results.

If you want to draw any kind of conclusion you should reduce the number
of variables.  Remove the compression, then compare Protocol 1 and 2
for an identical dataset.  If protocol 1 is consistently faster by any
significant margin then that might be worth looking into.

Then if you still want to play with compression test again with it on,
but remember that in Protocol 1 the compression level is variable
between 1 and 9 whereas in Protocol 2 it's fixed (in OpenSSH, at "6")
so make sure you're comparing apples and apples.


-- 
Configure bugmail: http://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.