Turning auto-negotation off drastically reduces network speed.

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
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
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
[root@gamunu pgunarat]# /sbin/mii-tool
eth0: 100 Mbit, full duplex, link ok

Any network activity at this point peforms anywhere from 1-10KB/sec.
In fact if a high speed download is in progress the speed will slowly
decrement until it reaches 10KB/sec.

----------Turning AutoNeg Back On----------
[root@gamunu pgunarat]# /sbin/ethtool -s eth0 autoneg on
[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
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
[root@gamunu pgunarat]# /sbin/mii-tool
eth0: negotiated 100baseTx-FD, link ok

Any network activity here will be at the usual/regular speeds
(500-5000KB/sec). If a download was in progress while autonegotiation
was turned off, after it is turned on it will immediately speed up to
the full speed upon turning auto negotiation back on.

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

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 experiencing this
problem). Could this problem be related to a faulty card as well or is
there something we are missing?

Thanks for your time, if any other information is needed let me know.

-Matt

A minor correction:

It is a 10/100 switch that myself and the other computers are connected
to, not a hub.

Also unplugging the switch, then plugging it back in and removing the
other computers has no effect.

-Matt

matt <(E-Mail Removed)> 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...

Rick,

You nailed the problem right on the head. By using:

ethtool -s eth0 autoneg off duplex half

it completely fixed the problem.

Thank you so much for your thorough and quick response. It was very
informative and I am actually printing it right now for future
reference.

Thank you,

Matt

matt <(E-Mail Removed)> wrote:
> You nailed the problem right on the head. By using:

> ethtool -s eth0 autoneg off duplex half

> it completely fixed the problem.

> Thank you so much for your thorough and quick response. It was very
> informative and I am actually printing it right now for future
> reference.

Glad to hear it. Just be sure that once you are done with your
experimentations that you put everything back to autoneg like it
should be

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
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...