Performance problems with new 100BaseT network

[Ruediger Noack]

Situation :
1. HP 9000/K570 (HP-UX 11.00) with Oracle access for backup, 3 LAN connections
2. HP 9000/K220 (HP-UX 10.20) - OmniBack cell server, 3 LAN connections
3. many other nodes in LAN 1

LAN connections
LAN1 : 100BaseT for intranet -- ok
LAN2 : FDDI only for OmniBack with 3 nodes (K570, K220 and a third server with DLT library) -- ok
LAN3 : 100BaseT to replace LAN2 with in this moment K220 und K570, this is a 16 address network (netmask fffffff0) -- with problems.

The problem :
Omniback over LAN2 (340GB) takes about 17h.
Omniback over LAN3 with DLT library on K200 takes about 27h.
Because of bad performance we reconfigured Omniback to use over LAN2 and DLT library on the 3, server and checked out LAN3.
We found out a few side effects :
1. ping via LAN3 -- ok
2. telnet/ftp via LAN3 -- we have to wait for login about 40 seconds.
3. netstat -rn -- response time ok
netstat -r -- display of the 2 raws for network LAN3 takes both about 80 seconds on K570, K220 ok.

LAN cards for LAN3 :
- PCI Ethernet (10110009) on K570 (ioscan output)
- HP HP-PB 100 Base TX card on K220 (ioscan output)

Anyone an idea ?
What performance do you get with OmniBack via 100BaseT ? 340GB/17h means about 45MBit/s and i think it is a realistic value for effective data.

Thanks
Ruediger

[Tim Malnati]

I think your problem here is that the K220 is using an HP-PB network card instead of an HSC interface. I believe this network card is derated if I recall correctly. Although you are connecting with 100 mbs speed, the card/bus combination is not providing full throughput.

[Jeremiah Campbell]

I found out from HP HW call that the HP-PB card does not provide "true" full-duplex. It only runs at half duplex internally, (from bus to interface card). This may be causing some problems for you.

[Bill Hassell]

The HPPB card (and bus) design will limit the maximum throughput of a data stream to about 40-50Mbits/sec. This is a hardware limitation but not related to full duplex in a backup situation. For backups (or other large data transfers), the data is virtually all simplex. That is, 99% of the data goes one way with a very small amount going the other way.

Full duplex has an advantage if data is being sent in both hdirections at exactly the same time, which isn't all that common without lots of processes doing lots of transfers at the same time.

The long telnet connect times is not normal though but given the through on the HPPB LAN card is approaching the hardware limit, the telnet issue is likely something quite different. Perhaps a DNS issue or network UDP or SYN flood or arp storm.

[Mike McKinlay]

You don't mention any interconnect devices. Is there a switching hub in the middle of this network? Confirm that all of the ports are defined for 100BT full duplex if that is how your NICs are configured. Don't pick an automatic adjust setting: hardset the ports on all the devices in the environment to 100BT.

[Mike Fitzgerald]

What you're reporting sounds like a duplex mismatch problem, so I agree with Mike McKinlay in that you should set all the devices and ports to fixed speed and duplex settings. Auto-negotiation should only be used on ports where people are walking up to plug in laptops, etc. Desktops, servers, inter-device links should always be set to fixed settings. Auto-negotiation requires that BOTH ends are set that way. If negotiation fails, the spec calls for it to fall back to 100/HALF, not 100/full as you'd probably prefer. A duplex mismatch most often manifests itself as a link that appears to work fine until you start doing bulk transfers like FTP and backups. Those things will crawl and often times will completely time-out.

[wyan lowe]

Hi,

If ping is ok, but telnet/ftp is very slow...
had the same problem: reverse-dns lookups are done by default.

check to make sure the boxes/cell manager are resolved correctly.
nslookup (hostname)

we had PCs with the same behavior trying to connect via tcp/ip to HP box.
ping from PCs worked fine.
telnet/ftp/custom app using tcp/ip - all experienced delay before finally working.
called HP - by default reverse dns lookup is enabled (10.20?)

the fix was to make sure the HP box could resolve the network/subnet that the PC was coming from: a db.10.1.1 file was created in /etc/named.data, but inside that file there isn't a PTR record for that PC. Just that the file/subnet exists and named knows about it, I guess was enough for the reverse lookup to complete without delay....

[Anthony Goonetilleke]

You might want to do a show ports on the switch the servers are connected to to make sure there are no errors.

[Andreas Voss]

Hallo Ruediger,

hatte leider bisher noch keine Zeit mit Dir Kontakt aufzunehmen.
Ich habe ab naechste Woche bis 1.9.00 Urlaub.
Melde mich dann bestimmt mal bei Dir :)

Viele Gruesse

Andreas

[Ruediger Noack]

Thanks for all replies.

I also contacted HP support with my problem. Here is the summary.

Response time (telnet, ...) was a DNS problem, also if i used only ip addresses !!! After editing /etc/hosts it is ok.
The bad throughput of my HP-PB 100BaseT is really caused in "bad card design". The card is offered for moderate performance. No chance for tune up ! Have to check if I find HSC cards here. They are for high performance.

Half or full duplex is no problem for backup use. The switches and the fibre channel between them - the network team swears - work fine.

Ruediger