Very Computer

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----------

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----------


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

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----------


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

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

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

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

Quote:> 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

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

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...

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

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...