Subject: Re: de0 on 164LX gives poor throughput
To: None <>
From: Hal Murray <>
List: port-alpha
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 
setup for. 

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