why isnt ftp faster after installing new NIC

[Dave Chamberlin]

Hello,
I have an RP7400 with 10/100bt core ethernet. I installed a 1000bt card and configured that as the primary interface. When doing transfer tests to my other servers, I get the same transfer rate when getting data from my rp8400 (with 1000bt) as with my other rp7400 which has 10/100. All interfaces are auto negotiating and the switch that connects them is supposed to be 1000bt as well. Whay am I not seeing a performance difference? Thanks

[Saurav_1]

Check the following points.

Do for all cards.
lanadmin -x .

Check your 1000bt card is working on full duplex and autonegotiation off. May be it is working on less speed. Network performance increases when autonegotiation is off. I have experienced this in most of the cases.

[Steven E. Protter]

Shalom,

If the lanadmin does not reveal a problem, its most likely the network infrastructure the NIC card is plugged into.

On a few occaisions the few years, I found 1000 BT cards plugged into 10 Base or 100 Base networks.

If you are running half duplex you can use lanadmin to force full duplex. Assuming the network supports it.

The theme here is the network configuration.

1000 BaseT cards must be set to autonegotiate on HP-UX boxes.

SEP

[Hemmetter]

Hi Dave,

We experienced a similar problem.
On a SD32000 running 11i having some gelan 1000SX NICs we reach a transfer rate of only poor ~14 Mbytes/s in a single rcp-session!

But we if we start more than one to about 8-10 rcp session, all that rcps run with that 14Mb/s. Only if the 1GBit linespeed is full utilized all the rcp-sessions slow down.

HP-Support statement was: "HP-UX (fixed)timeslice prevents a single process ( rcp session etc ) to saturate a 1Gbit LAN-line"

This accords with our tests with multiple rcp-sessions.


Has anyone here similar experience and can confirm this?

rgds
HGH

[sysadm_1]

Hi Dave,

Change the speed setting from AUTO to 1000bt on both sides.That is from switch side and server side fix it as 1000 instead of AUTO.
I found very good difference in performance after fixing the speed.


Cheers!!
sysadm

[Zinky · Accepted solution]

Peace & Clean Earth, Water and Air.

1000BT links should always be set to AUTO negotiate on the HBA and the switch end. Check your GigE interfaces on your rp7400 to show that your currently connected at 1000FDX and your negotiation is auto:

speedy# lanadmin -x 4
Speed = 1000 Full-Duplex.
Autonegotiation = On.

If the above checks out okay, then perform a pure FTP speed test as follows (this negates the effect of slow filesystems):

rp7400# ftp rp8400
user:
pass:
ftp> binary
ftp> put "|dd if=/dev/zero bs=1024k count=10240" /dev/null

The above transfers 10GB of data accross yuor GigE. You should get anywhere between 50 to 90 Megabytes/sec.

IF you do not get the above speed. Something is wronf with your LAN infrastructure. It is possible (and I have seen this a lot before) - that the switches your rp8400 and rp7400 are each plugged in may be on a staurated ISL or just a 100BT ISL one or routed (which you can quickly check if the LAN address of your rp7400 and rp8400 are differnet).

IF you LAN checks out okay and the pure FTP speed test yields expected throughput -- then it may be you rfilesystems that are at fault here (they're slow) -- either the source or the target filesystem.


Hope this helps.

[Dave Chamberlin]

Thanks for the many (though differing) replies. I have done the test with /dev/zero... etc and got 70MB/sec going from the rp8400 to the rp7400. That file btw - does not exist on my rp7400 - is it specific to 11.11? Is there a different file on the rp7400 I can use to perform that test from that server to others?

[Zinky]

Yes.. /dev/zero is specific for 11.11 systems but you can create it on 11.0 systems.

So -- what's your conclusion then? Slow disks eh?

[A. Clay Stephenson]

/dev/zero came along officially with 11.11 (& up) but you can create one yourself:

mknod /dev/zero c 3 0x04
chmod 444 /dev/zero

[Dave Chamberlin]

Well, lets not use a negative connotation like "slow". Source A has same speed disk as target, and source B has faster disk then target - but since I was pulling data - maybe target disk speed was the limiting factor in that test. Thanks

[rick jones]

A netperf TCP_STREAM test would be a good way to measure the performance of a NIC without effects from things like disc or FS performance.

WRT HP-UX timeslices precluding hitting link-rate on gigabit, must as I should support my fellow HPers, that is just plain wrong. I can and often do see link-rate with netperf TCP_STREAM tests with a single netperf. If rcp (or FTP) is unable to do that it suggests to me that something else is afoot - either the discs are not fast enough, or perhaps rcp or FTP are using too small a socket buffer.