HP-UX ftp issues

[Brem Belguebli]

Hi,
I'm having a little issue.

The ftp server (located in Japan is a HP-UX 11.23 wuftpd-2.6.1) runs with bufsiz 340k (ftpd -B 340).

I have 4 clients, located in Europe, on the same site, connected with Gb cards, 2 are Linux running lftp client with bufsiz 340k (set net:socket-buffer 340000) and 2 IA 64 HP-UX 11.23 running HP-UX ftp client with bufsiz 340000 (-B 340).
The 4 machines have tuned tcp parameters (window size > 500k).

the latency between the clients and the server is 250 ms.

The results obtained to transfer a 50 MB file from each machine are stable but embarrasing:

Linux: between 54 and 60 secs
HP-UX: between 2'10 and 2'40

What could explain such differences ?

[Suraj K Sankari]

Hi,

Did you checked the speed of all the network card speed and where connected switch/hub port speed if not then i think some different is there somewhere NIC and switch/routers

Check all the ports as well as cable (patch cord) also.

Suraj

[Brem Belguebli]

Machines are Gigabit connected, no duplex pb, or other thing.

2 of them (HP-UX and Linux) are blades on the same C-Class connected to the same switch.

The other HP-UX is a RX8640 connected to a core switch thru gigabit fiber and no errors on the link.

The last Linux is a DL585 with a fiber giga and no errors.

[Steven E. Protter]

Shalom,

It may have nothing to do with server configuration, these issues.

You have Linux and HP-UX systems involved.

Modern Linux systems use vsfptd which stands for very secure ftpd. Red Hat uses it on its own websites. It is very scalable.

With the Internet involved, the type of network card has little impact on the transaction. Run landadmin just to see the NIC cards are running at full duplex as that can cause i/o problems.

What is unclear at least to me is the network status of the HP-UX versus the Linux clients. The latency you see is 250 ms which is pretty good between Europe and Japan.

I would suggest the following:

Try using the clients in default configuration without special tuning. Normally on the client side, default works well.

On the HP-UX side monitor /var/adm/syslog/syslog.log for clues to the problem.

Perhaps do a network sniff with wireshark or tcpdump and see if there are problems impeding the transfer on the HP-UX side.

Many factors come to play here:
* Radically different clients.
* OS patching
* Firewall configuration
* Network duplex and other nddconf customizations.

I'd also like to know how latency was tested.

SEP

[Brem Belguebli]

Hi,

Thanks Steven for your reply.

The FTP server involved is, as I said in my previous post the HP-UX one which is located in Japan. The european machines are (HP-UX and Linux) only clients, so nothing to do with Redhat vftpd.

The link is built on top of SMW3, the shortest latency between Europe and Asia, thru the Red Sea.

Cards are all full duplex , without errors.

Default window size (32768), on HP-UX gives a transfer rate of around 1.5 Mbs at this latency, not an option for us.

As I said, window sizes have already been modified on HP-UX (nddconf, ndd -set /dev/tcp ...) and on Linux with the very same values.

I've already sniifed a lot of times the transfers, I can't see nothing except that it is taking longer to finish on HP-UX.

I'm confident it's a client issue, I've just compiled lftp for HP-UX (I use lftp on Linux)

I'll make another try.
Regards

[rick jones]

Verify that a test such as:

netperf -t TCP_STREAM -l -50m -H -- -s 340k -S 340k -m 64k

(replace lower case with upper case to switch from powers of ten to powers of two)

gives the desired throughput. In either case. That will take the FTP's out of the equation.

When you set sysctl settings on the linux systems which ones specifically did you set? There are two limits - one for autotuning, and one for explicit setsockopt()s. The latter is rather lower than the former.

It would be good to take snapshots of netstat statistics for TCP before and after the transfers and run them through beforeafter:

ftp://ftp.cup.hp.com/dist/networking/tools/

to see if there are retransmissions. If so it could indeed be a question of differences in the congestion control algorithms.