c8000s are slow on a 1000 / Gigbit network

[LV2DIVE]

Seems like the fiber 1000 cards are the problem slow, and the copper 1000 onboard is fast. All machines are HP c8000's with 11.11, and network is set to auto on both ends of cable.

Setup:
NFS Server has a Gig fiber to Gig Cisco switch
Clients have Gig copper to same switch.

FTP Speed tests:

From To Speed
Gig fiber Gig Copper 10.6MB/Sec.
Gig fiber Gig Fiber 11.1MB/Sec.
Gig copper Gig copper 79.8MB/Sec.

Transfers were a single 200 MB file via ftp.

Anyone had issues like this?

[rick jones · Accepted solution]

It would help to have a description of the NICs beyond just copper and fibre as there have been a number of different GbE NICs for 9000's over the years. ioscan -fk | grep lan might be helpful.

Also, are the multiple NICs in the one c8000 configured into the same IP subnet?

[Rasheed Tamton]

lanscan
lanadmin -x 0 (1 , 2, 3)
lanadmin -m 0
check the speed. Even if it is auto at both ends did you check whether it is half-duplex or full duplex.

lanadmin (menu) display - check all the settings including MTU.

Also make sure you have the correct updated drivers for all the NICs.

[Steven E. Protter]

Shalom,

HP-UX 11.11 often requires network speed be set manually in /etc/rc.config/hpbtlanconf in order to get speeds correctly on many network switches. You will want to also have the switch set for manual speed to insure proper connection.

Since you are working with 100 BaseT cards it is not unsual to expect slower speeds on your C8000. I do believe GB cards are available for these boxes.

SEP

[Patrick Wallek]

Ummm...SEP, if you go back and read the post again, you will notice he mentions copper 1000 and talks about GIG in his speed tests.

ALso, one can NOT hard set 1000FD speeds in the /etc/rc.config.d files. Gigabit REQUIRES that it be set to AUTO.

[Hein van den Heuvel]

>> NFS Server has a Gig fiber to Gig Cisco switch
>> Transfers were a single 200 MB file via ftp.

Hmmm, if I was concerned about the performance of an NFS server, then I would focus on NFS test. FTP tests may or might not excercise similar components, and they may help pin down a problem, but why guess, and why start there? What really counts is how welll the NFS files serving performs no?

The gig fiber is the only connection to the nfs server, and the nfs server is the only on connected with fiber. Correct?
So anythign blamed on the fiber, might be caused be a number any of a of network settings on the server and the fiber chanel might only be the messenger, being shot down.
- jumbo_frames ?
- tcp no del ack ?
- tcp window size ?
- tcp window scaling ?

There was a recent discussion in the OpenVMS forum on a similar problem which my help clarify some:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1112456

hth,
Hein van den Heuvel ( at gmail dot com )
HvdH Peformance Consulting

[rick jones]

NFS is request/response (even if you are "just" writing or reading to the file, it is a series of request/response transactions) where FTP is just blasting data one way.

I always look for packet losses and retransmsisions first. On the UX end, netstat -s and lanadmin -g mibstats - perhaps taking snapshots while an NFS transfer is going and running them through beforeafter: ftp://ftp.cup.hp.com/dist/networking/tools/beforeafter.c

After that, then I would wonder about mount sizes, the window size of the mount if TCP, and readahead/writebehind settings if any. (Been a long time since I've done much NFS tuning so I don't recall where to set those, perhaps Dave Olker will emerge from the shadows to chime-in here...