BTLAN on board network slow

[Paul Clayton]

RP7400 (N-Class). The on board BTLAN network point is very slow. We typically get about 19Kbytes a second data transfer. We are on QPK1100 March 2003. I have moved switch points and cables around, with no luck.
This is a reman server, just fresh built. At this stage nothing is running on the server that would possibly cause the network to be slow. Any ideas

[Paul Clayton]

Should have added that this data transfer test was done between many servers. All our RP7400 servers are at the same patch level. The test was done on the same subnet onto a Cisco 3500 XL switch.

[Duncan Edmonstone]

Try hard setting the speed of the card on the server and on the switch... assuming it is a 100BaseT card and is lan0:

lanadmin -X 0 100FD

Then get your network admin to tie the port speed down to 100FD with no autonegotiation...

see if this sorts it

HTH

Duncan

[Pete Randall]

Paul,

How about a duplex mismatch? Run "lanadmin -x 0", where 0 is the PPA number found from lanscan. Force it to full duplex with "lanadmin -X 100FD 0" and also change the settings on the switch and in /etc/rc.config.d/hpbase100conf.


Pete

[Duncan Edmonstone]

oops

Pete had the right order on the arguments for lanadmin...

lanadmin -X 100FD 0

ta

duncan

[Caesar_3]

Hello!

Check that all your network configured to
100 full duplex (switches and the NIC's).
Don't use the automatic way of speed select.

Caesar

[Paul Clayton]

Tried that. The switch is configure 100 full duplex as well as the card. Still no luck. Looking at the dat xfer stats, it is equivalent to 152Kbit link.

[Pete Randall]

Errors?


Pete

[Pete Randall]

Bad card?


Pete

[Stefan Farrelly]

In most cases this is a hardware/speed mismatch problem. I know youve said youve checked it, but its very easy to believe someone else rather than check yourself. I had this problem once and the network team swore their switch card was auto, and the HP was auto, and I contacted the switch people myself, and gess what, it didnt support auto!

Check on the HP speed;

lanadmin -x speed

It should report back;

Current Config = 100 Full-Duplex AUTONEG

As you can the HP card is set to auto, but has negotiated to 100Fd. You need to be 100% sure your switch port is also set to AUTO (not 100FD), so that both are the same. They will negotiate to 100FD by themselves.

Next, check errors to see if it is a speed mismatch;

lanadmin -g

The last section displayed shows errors. If you have any FCS errors then this indicates a speed mismatch. If you have carrier sense errors then this is a physical problem (cable/switch), eg. we had one today;

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 = 69524
Frames Too Long = 0
Internal MAC Receive Errors = 0

Normally all these stats are 0 (except Index=1)

Do you show any errors like this ?

[Paul Clayton]

Full marks to Stefan. We set the server to auto_on and the performance is back to 100Mbps
Interesting that I don't have the same problem on my other N-class servers, and only on this one.
Thanx for the help

[rick jones]

If setting the host to auto-on fixed the problem, then the switch was _NOT_ hardcoded wo 100FD.

How Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full duplex if both sides can do
full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.

So, the following table shows what will happen given various settings
on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going
well. Lucky means that things will likely go well, but not because you
did anything correctly :) Sorrow means that there _will_ be a duplex
mis-match.

On the side running half-uplex you will see various errors and
probably a number of late collisions. On the side running full-duplex
you will see things like FCS errors.