How to Speed up FTP between PC (win2k) and HP-UX 10.20

[Basheer_2]

I have a daily need to transfer(copy) tif files about 3000 Per day from HP-UX 10.20 to win2k.

Are there any parameters on win side and hp side to speed up ftp.

Or

Are there any other util/pgm can be used for this.

Thanks

[Uday_S_Ankolekar]

Check the network speed at both the ends..
If your card support full duplex then modify the speed settings on both the side.

-USA..

[Pete Randall]

Double check that your speed and duplex settings are correct on both the switch and the HP box. Auto-negotiation is always problematical, force it to 100FD.


Pete

[Paula J Frazer-Campbell]

Hi

Tiff file are opem to compression

Try gzip -9

Or tar up the whole list and then ftp them accross.

HTH

Paula

[John Bolene]

your 10.20 machine may only have a 10Mbit interface, for much better thruput it needs 100Mbit

there are no parameters to change for ftp

better yet, get GigE cards for both and use a dedicated crossover cable to connect them

[Chris Wilshaw]

We have a similar setup here.

One other thing to watch out for is anti-virus software on the PC server. If this is configured to scan files on write, it can double the length of time taken to FTP files from the unix server.

[A. Clay Stephenson]

TIFF allows for several forms of compression - one of which is uncompressed. You might try compressing before transmitting and then uncompressing on the other end. The overhead of FTP is about as small as it gets so no other transfer mechanism is going to significantly reduce the transfer.

The first thing that I would do is determine what the transfer rate is. FTP about a 10MB file and measure the throughput? Is it reasonable for your network hardware? If the transfer rate is much lower than expected then you almost certainly have a duplex mismatch.

I would also look into using the Perl Net::FTP package. It can make the transfer process easy and do error checking on each transfer -- and yes, Perl is available for free on PC's. The other software 'fix' is to determine if you really need to send this much data. You might actually only need to send the files that have changed. Search for Perl and FTP and you should find several examples on this Forum.

[William Wong_2]

Since you have 3000 of them are they in the same directory? If so you might want to create a single tar file of them and then compress them with gzip or zip. And then you can use Winzip on the PC side to uncompress/untar them all. The only other suggestion depends on how fast your network cards are between machines. If they are Gigabit network card you can gain efficiency by using a non-standard TCP stack.

[Jeffrey Killian]

Check the block size on the platforms. Our HP-UX 11.0 uses 64K blocks and Windows uses 4K blocks. Try these settings to establish a connection from W2K to HP:
ftp -i w:65536 hphost

The -i flag allows transfer of multiple file using mput without the pesky response request.

We use this and get pretty good transfer rates between Windows and HP box...

Other option for ftp (on the windows side) can be found by typing the ftp command with bad parameters in a DOS windows. The windows help for the ftp command is sorely lacking.

[Shannon Petry]

Some or alot of your probem has nothing to do with FTP, but rather some well documented problems with M$ changing standards to suite themselves, make them look good and others bad.

Lets look at some basic working, and what was done.

When a client and server talk, there is an initial network packet sent to see if the server is available from the client. (true when any 2 machines talk, but I'll use client server for clarity).

Upon receipt, the server sends back an ACK packet, to let the client know it's there, so talk away.

This standard has been around as long as TCP/IP.

This is where we see how M$ thinks...

With NT4, M$ started having clients listen for 2 ACKs from the server, and had their servers send 2ACK back to clients.

If only 1 ACK was received by either side, then the host was considered to be on a crippled network, and given 1/2 bandwidth.

Of course this makes everyone but NT look slow on the network. For the first time, M$ could say it was better at networking with their crappy IP stack than anyone else.

This behavior was noted withing a couple months release of NT. The controlling body for TCP/IP standards was basically told to screw themselves by M$, and they M$ has stuck to this standard.

SunOS, Linux, and AIX all changed their IP stack to accept and send 2 ACKS, but dont treat anyone sending 1 ACK back as crippled. The second ACK sent to servers is usually ignored.

Now, I do not know if HP or Irix also modified it's IP stacks to do something similar.

In 100baseT networks, this is not nearly as noticable as it is in 10BaseT or BNC networks.



Regards,
Shannon