rcp is faster than ftp?

[mehul_3]

Hi,
Is rcp is faster than ftp? My datafile is of 18GB and WAN has a BW of 2mbps.So how much appro. time will be required to transfer file using rcp.

Mehul

[Steven E. Protter]

Answer: It depends.

It depends on the speed of your network, switches, network settings and the other load on the various componeents between point A and point B.

Both protocols will transmit authentication in clear text.

Because there are so many variable factors the real way to answer your question is to transfer the file both ways.

I'd recommend scp myself.

http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=T1471AA

SEP

[Ivajlo Yanakiev]

I think that ftp is faster.
This protocol is design for File transfer.

[Bill Hassell]

ftp is definitetly faster. rcp is a simple read and write one record at a time and does not try to maximize the data transfer. It has more overhead per block of data. ftp is adaptive to the link speed and allows for multiple blocks to be in the pipeline while waiting for acknowledgements. ftp does have more overhead in getting each file started using the control channel but for large files (multi-megabyte and larger), this is negligible.

[Ranjith_5]

Hi Mehul,

In my experience FTP is faster than RCP . I use FTP to transfer large data to my remote server.

Regards,
Syam

[Andrew Cowan]

You can push even more speed out of ft if you tune your IP Stack to suit your network. One of the easiest and quickest gains is to increase the MTU size to the maximum that your switches can handle before they start to fragment the packets.

[Fred Ruffet]

Nothing is faster than FTP :)
I agree in the fact that clear password will go through your network with both FTP and RCP so that SFTP or SCP are "better" (security speaking). But note that those two last protocols will spend many time and CPU encrypting and decrypting file on both sending and receiving machines and that for a 18GB file it must be something you need to think about.

Regards,

Fred

[Andrew Cowan]

If you want speed and are worried about security simply ftp between two unprivileged accounts and compress the file before transfer, this way if an attacker gains access to this account you should be able to monitor and detect this quite easily, and any damage they can do will be limited.

[rick jones · Accepted solution]

Given you are using a WAN, and given that both rcp and FTP basically dump the large file into the TCP connection, the limiting factor here will likely be the latency of your WAN link and the size of the TCP window and socket buffers on each end.

For HP-UX, both rcp and FTP default to a 56KB socket buffer and hence 56 KB window. Sufficiently contemporary patches should allow you to set socket buffer sizes larger than that. The socket buffer size at time of connection establishment will determine the TCP window.

Basically, run a ping across your WAN, or a netperf TCP_RR test. Take the latency, in units of seconds, and multiply that by the bandwidth of your WAN link. That is the "bandwidth delay product." You want a socket buffer that is at least that large. You might consider padding it by, oh, 50%.

After that, the only remaining question is the loss rate of your WAN link...