poor ftp performance

[Antonio Galán]

I'm trying to send a lot of files using FTP but the performance of this sending is not as good I would like.

It seems the solution is to change Auto-negotiation from On to Off in network connection characteristics (as I've read from other threads), but I don't know how to do it in hp-ux 10.20. In fact, I don't know how to see if auto-negotiation is on or off, because this information is not shown by lanadmin

Thanks in advance

[Rick Garland]

Check to see what speed you are running at. This could very well be the root of the performance problems. Have the router/switch port checked to see if it is at the speed you want as well. As to the auto-negotiate, I usually leave it off. To check the LAN interface, use lanscan to find the NMID of the LAN you are using. With that value, you can use 'lanadmin -x NMID#' to check the settings of the card. Note, you may have to load some patches to enable this to work. The patches to load are dependent on the type of driver being used for the LAN.

To lock down the LAN config, use one of the start scripts in the /etc/rc.config.d. The specific file to modify will depend on the driver being used as well. An example of a file is the 'hpbasetconf', but remember this will depend on the LAN driver in use. Config of this file will lock down the card at a specific setting that you define. Don't forget that the port (switch) will need to be set correctly as well.

There are previous posts regarding the patches to use and the file to config based on the LAN driver.

[Antonio Galán]

Thanks Rick.

I have used lanadmin without any parameter and this program shows that speed is

10000000

but if I try to send 1200 files of about 1700 bytes each, it takes 250 seconds.

[Rick Garland]

Do you want to be at 10mps?

Using the lanadmin command with the -x option will tell you if it is at 10, 100, full duplex, half duplex, auto negotiate on or off.

For 10.20, use the NMID#, for 11.00 use the snap#. These values can be obtained from the lanscan.

[rick jones]

1200 files in 250 seconds is about what one might expect to see if you are using ftp and say something like "mput" or pass a list. the reasons have to do with the way the control channel behaves and would have nothing to do with lin card settings (i prefer to keep autonegotiation myself...)

If you want to get the files across faster, you might try rcp, or taring the files into a tar file and then untaring at the end.

If you were to run the same test between a pair of 11.0 systems, I would expect the file rate to increase - the standalone ack timer is 50 milliseconds in 11.0 and 200 in 10.20 and other BSDish stacks. With that clue, and a suggestion to use tcpdump to watch the control connection the inquisitive reader can figure-out what the control channel does that limits successive file transfers to 5 per second :)

[Philip Chan_1]

Hi Antonio,

Consider using "rsync" if you would like higher transfer speed. Rsync could compress the sending data for improving efficiency. My experience is that this program need less than half of the ftp time when sending large amount of data.

Rsync link,

http://rsync.samba.org/

Have a look and you may like it.

Rgds,
Philip

[Antonio Galán]

Thanks everybody for your answers

I think the cause of the poor performance I have described is due to the reason Rick Jones indicated because for every sent file, ftp shows

1700 bytes sent in 0.00 seconds (8247.32 Kbytes/s)

Then the problem is not the speed but he standalone ack timer. Is there any way to modify it? In fact, I can't find its value because I can?t find the file 'tcpdump'