Send and Receive Packets on Giga-Bit NIC Increase Performance

[P Turner]

Hi

Can anyone help me please .I have a problem. Its on a HP server running 11.I. Not sure what the model of the server is.
Problem is performance. It is the performance through the NIC, while running backups using Sabre/Tina/Time-Navigator on there backup server. This setting has been changed on another estate of servers running a different O/S and is now perfect.

I need to UP! The through put of the packets through the network, through the NIC, of which is a GIGA BIT card. The card is set correctly. Full Duplex etc…
It’s the Send Space / Receive Space that needs to be upped, apparently.

I have been looking at Kernel Parameters / ndd / lanadmin all to pretty much no avail. Is their such a setting in HP-UX to do this. They want the packets at 524288 bytes (512K).

Does anyone know how to set this?

Much appreciated if you could help

Rich

P.S. Have 10 points!!!!!!!!!

P.S. this thread has been moved from HP-UX > System Administration to HP-UX > networking - HP Forums Moderator

[Dave Hutton · Accepted solution]

Actually gig cards are not supposed to be hardset. I'm assuming by what you said "The card is set correctly. Full Duplex" you mean you did a lanadmin -x and it returns it.

[P Turner]

yes Thats correct!

I dont know here but just read something about Jumbo Frame Size. Its the Data size I want not the speed. Maybe I was not clear. Could this be what I want
i.e. 1500 stand Frames 9000 Jumbo Frames.

Im lost here perhaps you know if i have hit the nail on the head?

Rich

[Steven E. Protter]

Shalom,

I dont know here but just read something about Jumbo Frame Size. Its the Data size I want not the speed. Maybe I was not clear. Could this be what I want
i.e. 1500 stand Frames 9000 Jumbo Frames.

Follow the guidelines for the application. Jumbo frame size is probably not going to help.

GB cards must be auto negotiate.
The switch port settings ASLO MUST be auto negotiate. Manual settings in either case will seriously impede performance.

This does not apply to ndd commands. I would not be playing around too much unless your application vendor recommends it.

SEP

[spex]

Just out of curiosity, what kind of throughput are you getting now?

[P Turner]

Thanks but Auto Neg is Speed not Data size

Rich

[P Turner]

Honest
I dont know as this was just handed over to me at 5pm as someone walked out. But not good enough as the backups are choking.

This has been changed on other O/S servers and resolved problem. Just need it to pump more data through.

Rich

[P Turner]

Any more Ideas anyone

??

Rich

[spex]

Rich,

You can adjust the MTU size for the interface via:

# lanadmin -M

Is this what you mean by "data size"?

PCS

[Dave Hutton]

There is a doc here:

And look for:
http://www.psc.edu/networking/projects/tcptune/historical.php#HP

Procedure for raising network limits under HPUX 11

I guess the question isn't can you up it. It's if you should do it.

It also talks about netperf "including information about the "netperf" tool and a large database of system performance results obtained with netperf: "

Maybe you can look at the database of system performance results and get an idea of if it'll help.

Any chance its not network bound and more CPU or disk bound?

[rick jones]

You cannot have "packets" at 512K - you could have the TCP windows at 512K by changing ndd settings - the psc link may help there, or you can try this somewhat dated doc:

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt

make sure you have nearly no TCP retransmissions - snapshot netstat -s -p tcp 30 seconds apart and run the results through beforeafter:

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

Also, make sure your gig card is running at a gig:

lanadmin -g mibstats

and look at the interface speed bit.

Also, check the CPU util of _all_ the CPus in the system individually - not in aggregate. You want to make sure that no one CPU (say taking NIC interrupts) is pegged.

Try some netperf TCP_STREAM tests between this system and the backup server, and vary the settings there. http://www.netperf.org/

[P Turner]

OK All

Thanks for all the help

Hope the Points helped

I will have a go at this

Thanks.

I will post later as to how I get on

Thanks again

Rich

[Alzhy]

Can you send us the output of your GigE's connection details:

lanadmin -x 0

if you GigE interface is lan0?

Gigabit interfaces SHOULD always be left at its default settings which is AUTO-NEGOTIATE - only IF you want full Gigabit Speeds.

On 11.11, expect 60-80 Megabytes/second throughput and up to 25,000 packets / sec. on a GigE connection.

An Update to the GIGETHER package will add TCP/OFFLOAD features which will lessen CPU demands of your network activity. You may want to look at upgrading yur GIGETHER subsystem if you notice your network activity (intense backups or tyransfers accross your network) is causing increased CPU activity.

Hope this helps.

[rick jones]

Well, unless I'm mistaken (which is possible) the only offloads Gigabit Ethernet NICs on HP-UX offer are CKO and large send. So, if "offload" was meant to imply TOE (offloading the TCP stack) I suspect that isn't going to happen with 1 Gigabit Ethernet interfaces.

[Alzhy]

Rick, can you expand more please on your last statement that TCP/Offload is not possible with just 1 NIC?

You're aware of http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=GigEtherEnh-01 - right?

[Laurent Menase]

Hi Rich,

Yes you have on one hand the jumbo frame. But they need back to back connections or specific switches which accept it.
and you have TSO ( Transport segmentation offload).
with that you will specify a vmtu ( virtual mtu)

[rick jones]

Just saying "TCP Offload" implies the whole (or a significant chunk) of TCP processing is offloaded, and the NIC actually knows something about TCP.

TCP _Segmentation Offload_ is a very specific thing, whereby the NIC only knows how to segment a larger blob into smaller blobs that fit on the wire. It doesn't _really_ know much of anything about TCP.

Such an offload, along with Checksum Offload (which is a pre-requisit for TSO) can be called (in politically incorrect terms I suppose) an "idiot savant" offload - it is doing something purely by wrote with no actual understanding.