Re: Turning auto-negotation off drastically reduces network speed.

matt <usfmatt@xxxxxxxxx> wrote:
Let me get some information out of the way before the description:

NIC: Intel Pro/1000MT 82540EM
OS: Fedora Core 3
Ethtool Version: 1.8

I am currently working on a project for my university and just
recently ran into some difficulties. I am using ethtool to adjust
the speed of the Intel NIC mentioned above. To change the speed I
must first issue the command:

ethtool -s eth0 autoneg off

My problem is when I issue that command my network connection drops to
1-10KB/sec. When I issue the command:

ethtool -s eth0 autoneg on OR just don' t turn it off (like on a fresh
boot)

My network speed is the usualy 500-5000KB/sec.

Here is all the relevant output:

----------Settings before any changes----------

[root@gamunu pgunarat]# /sbin/ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full

This means the other side of the wire is also doing autoneg, for
reasons explained later.

Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes

----------Turning AutoNeg Off----------
[root@gamunu pgunarat]# /sbin/ethtool -s eth0 autoneg off
[root@gamunu pgunarat]# /sbin/ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full

This means you have a duplex mismatch, for reasons which should become
clear later :)

Both the PhD student I am working with and myself are at a loss.

Speaking as someone with "just" a BS I'm sure there is a wisecrack
about PhD's there somewhere :)

We do believe the network card is faulty because a few times a day
it will completely drop any network connection (even when we are not
changing any settings, just web browsing, email, etc) and the
ethernet cable must be unplugged and plugged back in. We believe it
is the adapter on the card and have ordered a new one (we tested the
cable, and the hub is connected to 3 other computers not

Drift - if it supports full-duplex, 99 times out of 10 it is not a
"hub" even if that is what the salescritters call them. It is a
switch. Hubs are half-duplex devices. (or if you want to go further
back into the mists of Ethernet terminology time, IIRC switch would be
"multi-port bridge" and hub would be "multi-port repeater")

experiencing this problem). Could this problem be related to a
faulty card as well or is there something we are missing?

Here is a bit of boilerplate about autoneg which will hopefully
provide sufficient enlightenment about what happens when you are
messing about with settings:

How 100Base-T 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.

When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of _LATE_ collisions
("normal" collisions don't count here). On the side running
full-duplex you will see things like FCS errors. Note that those
errors are not necessarily conclusive, they are simply indicators.

Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.

hth,

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
.

Relevant Pages