eepro100 performance problems
Andrew M. Kuchling
akuchlin@mems-exchange.org
Thu Jun 17 14:04:07 1999
A few weeks ago I asked about how to force an eepro100 card into
100baseT-FD mode, and got a helpful answer telling me how to do that.
However, we're still struggling to see any improvements in the card's
actual performance, for unknown reasons. netperf reports:
TCP STREAM TEST to hostname
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
65535 8192 8192 10.00 11.59
This is obviously much less performance than we're expecting to see.
Bruce, the network person who's trying to get this to work, wrote:
>Currently I am suspecting that the board is not setting itself to
>100 full duplex, possibly 100 half duplex.
>The switch is set to 100 full duplex and they are talking to each oter,
>but the speed is still piss poor. So they may be thrashing in
>negotiating full duplex or some such.
He's suggested it might be a defective board, saying:
>The reason I am
>saying this is because after setting the board to 100 FD, it was not able
>to autonegotiate with the switch, which was set to autonegotiate. After I
>switched the switch to 100 FD, it was able to make a connection. Usually
>when autonegotiation fails, it doesn't fail completely, it just keeps
>trying, the result being about 3mbs thruput.ie toggling on and off to 10
>mbs.
I've included the output of eepro100-diag, mii-diag, and the kernel
bootup below, and will happily run any other tests that are suggested.
Suggestions about how to solve this would be very welcome:
* How can we diagnose the cause of this problem?
* Is this due to a misconfiguration on our part? (Wouldn't
surprise me at all; this is all outside my past experience...)
* Could it really be a defective board?
* Is trying v1.08 of the driver likely to help, by fixing some
bug that would cause such behaviour? (The machine is located in a
clean room on the other side of the country from me, so I've been
reluctant to enter on a round of kernel recompiles.)
I can equally imagine that netperf is reporting incorrect results, or
the packet size used in the tests tickles some TCP misbehaviour in the
kernel that slows things down, but lack the experience to know whether
that's the case.
Heartfelt thanks in advance; this problem is driving us up the wall...
--
A.M. Kuchling http://starship.python.net/crew/amk/
Can't say I've ever been too fond of beginnings, myself. Messy little things.
Give me a good ending any time. You know where you are with an ending.
-- The eldest of the three Fates, in SANDMAN #57: "The Kindly Ones:1"
=========================
Kernel output on bootup (this is with kernel 2.0.35):
eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eth0: OEM i82557/i82558 10/100 Ethernet at 0xb800, 00:A0:C9:EE:FA:9F, IRQ 10.
Board assembly 697680-001, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x24c9f043).
Receiver lock-up workaround activated.
eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
[root@memscope scope]# ./mii-diag
Using the default interface 'eth0'.
MII PHY #1 transceiver registers:
2100 780d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a03 0000 0001 0000 0000 0000 0000 0000
0000 0000 c6e3 0000 ffff ffff ffff ffff.
Basic mode control register 0x2100: Auto-negotiation disabled!
Speed fixed at 100 mbps, full-duplex.
Basic mode status register 0x780d ... 780d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 40a1: 100baseTx 10baseT.
Negotiation completed.
[root@memscope scope]#
I'm not sure why only 100baseTx and 10baseT are listed as the link
partner capability, but Bruce may have reconfigured the switch to
disable full-duplex mode as part of his efforts to solve this.
[root@memscope scope]# ./eepro100-diag -f -e -e
eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0xb800.
EEPROM contents:
a000 eec9 9ffa 0100 0000 0201 4701 0000
6976 8001 4581 0009 8086 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 926e
The EEPROM checksum (should be 0xbaba) is 0xbaba.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:A0:C9:EE:FA:9F.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 697680-001, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.