Subject: Re: de0 on 164LX gives poor throughput
To: None <email@example.com>
From: Hal Murray <firstname.lastname@example.org>
Date: 04/10/1999 11:33:18
> I believe ifconfig de0 will show it is in full-duplex mode if that was
> selected. None of the interfaces I am talking about have this enabled.
I haven't worked with the 164LX.
On the Miata, the console sets a "mode" for the Tulip. That gets
passed to the DUnix driver somehow. I don't know if that's via something
in low memory or a value in a CSR in the Tulip. The DUnix driver
uses the mode set by the console if you don't tell it anything else.
One mode is "auto". The driver is supposed to automagically figure
out what to do by talking to the other end. Generally, I've had
good luck with this. (And I've been burned a few times when I tried
to force things and didn't get it right.) I gather that bugs in
this area are not uncommon.
When I was installing 1.3K last night, I has a Miata connected to
an Alteon (10/100/1000) switch. Performance was useless. The switch
was in full duplex mode. (I wasn't smart enough to look at the Miata
side.) When turning on the network, I used "auto" mode because that's
what the install script offered me, I couldn't think of anything
else to type (and didn't have any other NetBSD system where I could
check the man pages and...) Besides, that's what the console was
Everything worked fine after I forced the switch to half-duplex.
I did some testing last Nov on whatever was -current then. I couldn't
get 100 full-duplex to work on a Tulip. I didn't try very hard because
we had encountered troubles with the same driver on Intel boxes.
I might have missed something.
If anybody has a recipe that makes a Tulip work at 100-fdx, please
let me know. I can setup a switch (Alteon) or a point-point link.
I have one machine with an Intel 82588 in it. It seems happy, but
I haven't hit it very hard yet. The card is a Comapq NC3121 if that