[3099] in Release_7.7_team
Poor GX150 performance revisited.
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Jan 24 21:06:21 2002
Message-ID: <gwI=qPpz0001IZWVFl@mit.edu>
Date: Fri, 25 Jan 2002 02:06:19 +0000 ()
From: Bill Cattey <wdc@MIT.EDU>
To: net-help@MIT.EDU, release-team@MIT.EDU
CC: amb@MIT.EDU, ops@MIT.EDU
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
