[3101] in Release_7.7_team
Re: Poor GX150 performance revisited.
daemon@ATHENA.MIT.EDU (Carter Snowden)
Fri Jan 25 11:32:39 2002
Message-Id: <200201251632.LAA24770@astrophel.mit.edu>
To: Bill Cattey <wdc@MIT.EDU>
Cc: net-help@MIT.EDU, release-team@MIT.EDU, amb@MIT.EDU, ops@MIT.EDU
In-Reply-To: Your message of "Fri, 25 Jan 2002 02:06:19 GMT."
<gwI=qPpz0001IZWVFl@mit.edu>
Date: Fri, 25 Jan 2002 11:32:38 -0500
From: Carter Snowden <csnowden@MIT.EDU>
Hi -
I've had bad performance on my GX150 as well recently and have been taking
sporadic (and unsuccessful) stabs at trying to figure out what's wrong. I
started with the assumption that it probably had to do with some of the
local things I have added to my machine, as the GX150 in our test cluster
(which, theoretically, anyway, should be exactly like machines out in the
clusters) has continued to run just fine.
At any rate, I was about to give up on the local modifications screwing
things up theory and report it to release team, so Bill's message comes at
a good time. I would guess to about a 95% certainty that this is the problem
I've been having as well.
CS
>Some of you remember helping me crowbar my GX150 into 100-Base-T Full
>duplex to remedy very poor network performance.
>
>I stopped into 1-142 this evening to check my email, and I discovered
>that at least 2 of the GX150's there ALSO suffer from extremely poor
>network performance of exactly the same sort found myself.
>
>I think the reason why nobody reports problems is that when eventually
>the bits get into the AFS cache, performance is just fine.
>
>The system I am using to send this note is m1-142-13.
>It says it's autonegotiated 10Base-T full duplex.
>I experienced the same performance problem with m1-142-12.
>A user in the cluster ALSO experienced horrendous network performance on
>m1-142-8, but just didn't know that the MIT home page wasn't supposed to
>come up that slowly until I asked!
>
>Using the mii-diag program supplied by Donald Becker's web site, I
>poked at the speed and duplex setting for m1-142-12. It does indeed
>seem like autonegotiation is flako. But I was dissatisfied with network
>performace until after the SECOND time I told it to force
>100/full-duplex.
>
>At the present time, m1-142-13 and m1-142-8 have been left in the state
>I found them: autonegotiated 10Base-T, with really poor performance
>m1-142-12 is advertising autonegotiate, and is presently happy with
>100Base-T full-duplex successfully negotiated.
>
>Becker says this fault is due to early runs of the chip set giving bogus
>data in auto-negotiation. He says that the "alternate 3c59x driver" (IE
>the one on his home page) compensates for this bogosity. The RedHat
>driver, even for 7.2 has not been updated. Red Hat has not responded to
>my request to evaluate updating their driver.
>
>Next Steps:
>
>I'm officially informing you folks in the Networking group, that there
>is a problem with Linux 100Base-T negotiation with GX150's that Athena
>has. The problem is only noticeable to someone who does NOT expect
>"Athena and MIT net to flake out and take forever to load netscape
>sometimes."
>
>I am officially raising the suggestion at Release Team that we
>investigate Becker's assertions and his alternate driver, since that may
>turn out to be the simplest way to fix this.
>
>QUESTION to NetOps: What do y'all do with equipment on a subnet that is
>bad at autonegotiation?
>
>Does anyone besides me think it might be a good idea to write a little
>program to check the network performance on GX150's and crowbar their
>autonegotiate into a decent state?
>
>-wdc
