FTP ?

[Stephen Watson_1]

Having problems with FTP ascii transfers and web traffic. FTP Binary transfers appear to be fine, but ASCII transfer mode and web server response is very slow.
The box is typically used for demo's at customer sites, and is run off of a network most of the time. With the client and server hooked to the same hub, everything seems ok. Once back on the network, anything hooked to the hub is ok, but the rest of the network sees slow response.
Suggestions would be appreciated. Upgraded to HPUX11 recently (didn't have the problem with HP10.20).

[Stephen Watson_1]

more info on network setup:

lanscan

Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
8/0/20/0 0x00108303B98D 0 UP lan0 snap0 1 ETHER Yes 119

ifconfig lan0
lan0: flags=843
inet 3.19.108.62 netmask fffffc00 broadcast 3.19.111.255

netstat -nr
Routing tables
Dest/Netmask Gateway Flags Refs Use Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 44931 lo0 4136
3.19.108.62 3.19.108.62 UH 0 0 lan0 4136
3.19.108.0 3.19.108.62 U 2 0 lan0 1500
127.0.0.0 127.0.0.1 U 0 0 lo0 4136
default 3.19.108.25 UG 0 0 lan0 1500

ioscan -fnkClan
Class I H/W Path Driver S/W State H/W Type Description
=====================================================================
lan 0 8/0/20/0 btlan3 CLAIMED INTERFACE PCI(10110019) -- Built-
in #1
/dev/ether0
lanadmin

LAN INTERFACE STATUS DISPLAY
Tue , Mar 27,2001 22:56:50

PPA Number = 0
Description = lan0 Hewlett-Packard 10/100 TX Full-Duplex Man
ual TT = 1500
Type (value) = ethernet-csmacd(6)
MTU Size = 1500
Speed = 100000000
Station Address = 0x108303b98d
Administration Status (value) = up(1)
Operation Status (value) = up(1)
Last Change = 6134
Inbound Octets = 1525856
Inbound Unicast Packets = 1399
Inbound Non-Unicast Packets = 9977
Inbound Discards = 0
Inbound Errors = 0
Inbound Unknown Protocols = 8491
Outbound Octets = 154516
Outbound Unicast Packets = 1767
Outbound Non-Unicast Packets = 2
Outbound Discards = 0
Outbound Errors = 0
Outbound Queue Length = 0
Specific = 655367

Ethernet-like Statistics Group

Index = 1
Alignment Errors = 0
FCS Errors = 0
Single Collision Frames = 0
Multiple Collision Frames = 0
Deferred Transmissions = 0
Late Collisions = 0
Excessive Collisions = 0
Internal MAC Transmit Errors = 0
Carrier Sense Errors = 0
Frames Too Long = 0
Internal MAC Receive Errors = 0

[Steven Sim Kok Leong]

Hi,

I presume that when you mention connecting to the rest of the network, it meant connecting your LAN to the rest of the Internet. You have no performance issues with your local LAN (on the same hub) but you have performance issues when connecting to the rest of the network.

Between your LAN and the Internet lies:
1) The physical uplink from your hub to the switch.
2) The router between your LAN and the rest of the Internet.

You have contrasted FTP'ing of binary files and the FTP'ing of ascii files, how did the figures of the throughput compare?

Can you perform a traceroute from your FTP client to the FTP server? What is the response time at each hop?

Are you using any FTP proxy between your FTP client and your FTP server? If an FTP proxy is used, how selective is it in its caching?

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Brian Hackley]

Stephen,

Here are some notes I thought of when looking at this posting:
1. Do you see the same problem FTP/http to/from systems on the same IP subnet/local LAN as the HP system exhibiting the problem, or only with systems on the other side of the default gateway?
2. If seeing problem only on other side of the default gateway then you need to check to see if the HP is sending ICMP source quench. Typically a router admin can check that, or a sniffer, also netstat -p icmp might tell you (not all the fields are implemented). See ITRC Knowledge Base doc #WTECKBQA00000067 for assistance with ICMP source quench.
3. Is the HP system actually hooked up to a 100BaseT switch port and not a HUB? HUB's can only support half duplex mode, and your LAN is set for FULL Duplex.
4. Finally if none of the above helps, get a Sniffer or nettl trace going to help you collect data to pinpoint root cause.

Hope this helps,

-> Brian Hackley

[rick jones]

On hp-ux 11, a binary ftp transfer _from_ a server _to_ a client will make use of the sendfile() system call to significantly reduce CPU utilization. Early enough revs of the FTP server code simply called sendfile() for the entire file at once. in some aggregate FTP server testing I did, I found that with enough of these running at one time, other things on the system could become somewhat unresponsive. (ftp://ftp.cup.hp.com/dist/networking/briefs/)

Later FTP patches had FTP call sendfile() in chunks. This meant that it could be pre-empted just like it could before, when all it did was call read() on the file and send() on the socket.

Unlike a binary FTP transfer, an ASCII FTP transfer has the ftp daemon scanning all the bytes of the file as it sends it. This means the ftpd needs more CPU cycles to do that scan, and it means it uses send() rather than sendfile(). A web server often has more work to do than just calling sendfile() on a file containing a URL. Perhaps even scanning the URL's for server-side includes.

So, when the binary FTP's are "good" and the ASCII FTP's are "bad" what is the CPU loading on the system? If the CPU loading is high (near to 100%) you might make sure that you are up on the latest FTP patch.

The points made about hubs versus switches are good ones. Hubs are always half-duplex, and a duplex mis-match can ruin your whole day. However, duplex mis-match would not discriminate between an ASCII and binary FTP transfer. It would likely toast all transfers equally.