file transfer rate (ftp)

[masauso zimba]

When I transfer a large file between two digital unix servers the transfer rates are alarmingly far apart. One way takes more than 8 hours and the other way takes less than two hours for the same file. What parameters (network) do I need to check on both severs and compare.
What commands can I use to check the network performance.

[Pete Randall]

Check the speed and duplex settings on your NIC's. They need to match both at the NIC and at the router. If the NIC is 100MB/s Full Duplex, for example, the switch should also be set to 100FD.

Pete

[Ken Hubnik_2]

I would check the speed and duplex on each side.

lanadmin -x lan0

[T G Manikandan]

If the two servers are on the two different networks you need to definitely look at the route packets travel.


Just do a traceroute from serverA to serverB and
vice versa.

/usr/contrib/bin/traceroute

[Tom Jackson]

Hi:

You need to speficy the PPA number in the lanadmin -x command:

lanadmin -x 0 (for lan0)

You can also enter landamin, then select lan, then display to get some useful interface stats.

hth,

Tom

[Tom Jackson]

There is also a -B option for the ftp command. It allows you to specify the buffer size of the data socket. Valid range is 1-64. Default is 56.

ftp -B 64

Would set the buffer size to 64K.

Tom

[rick jones]

If you are on the latest FTP from HP (I think it is on software.hp.com), then the -B option should allow something much larger than 64K.

Increasing FTP's socket buffer would be indicated if the expression W/RTT where W is the TCP window size (aka the socket buffer being set with -B) and RTT is the round-trip-time between the two systems (ping being a decent first approximation, but best run while a transfer is in progress).

If there are indeed duplex mismatches, lanadmin will show FCS errors (when the NIC is in full duplex and the switch is not) or late collisions (when the NIC is in half-duplex and the switch is not.

There should also be TCP retransmissions reported on the sending side (netstat -p tcp) and out-of-order segments reported on the recieving side (again netstat -p tcp)

If lanadmin is "clean" but netstat not, then you need to start looking for other sources of packet loss between the two systems. Take traceroutes on each system, directed at the other, see if the paths are the same, and check the stats for each router in the path.

Other things that affect FTP would include filesystem perf - check that one system isn't disc-bound or something. To eliminate disc/fs overheads, you might try testing the speed between the two systems with netperf and the TCP_STREAM or TCP_MAERTS (TCP_STREAM from the netserver side to the netperf) tests. http://www.netperf.org/ or I suspect your friendly neighborhood HP support rep can get you a copy :)