Matthias Drochner writes:
> 
> explorer@flame.org said:
> > BTW, one tulip-based card I have at home works perfectly under windows
> > in that full duplex 100 mbps connections are reliably negoitated, but
> > under NetBSD it does not. 
> 
> What kind of card?
> '143 based cards (as my newer DE500s and the PWS onboard interface)
> using the internal (non-MII) PHY definitely fail to autonegotiate
> because there is no code in the de driver to deal with it.
> Manually setting to full-duplex doesn't work either,
> so the only way is to use simplex mode.

[my discussion is about NetBSD/i386 boxes, so I trimmed port-alpha]
FWIW, I have the following card:

de0 at pci0 dev 19 function 0
de0: interrupting at irq 9
de0: SMC 9332DST 21140 [10-100Mb/s] pass 1.1
de0: address 00:00:c0:35:6e:bf
de0: enabling 100baseTX port

I have it hardcoded in /etc/ifconfig.de0 like this:
	media 100basetx mediaopt full-duplex	

I have the Cisco 2916M-XL hard-coded as well like this:
	interface FastEthernet0/6
	 speed 100
	 duplex full
	 spanning-tree portfast

Running ttcp in both directions at once, from another machine with the
following card, I see quite respectable numbers.
(this card is auto negotiating; an early FA-310TX)
de0 at pci0 dev 16 function 0
de0: interrupting at irq 5
de0: 21140A [10-100Mb/s] pass 2.2
de0: address 00:40:05:40:f7:60

I started the 'ttcp -n 16384 -r -s' processes in the background on each
end, then started the transmit ends by hand, so there was a slight lag
before the second started, about .5s I guess. (enter/alt-tab/enter)

As you can see, the cards achieved a combined rate of 15085.18 KB/sec 
which clearly demonstrates they were running in full-duplex. :-)
But since one finished early, I should really adjust to a 15 second
run.  :-)

ttcp-t: buflen=8192, nbuf=16384, align=16384/0, port=5001  tcp  -> gillham
ttcp-t: socket
ttcp-t: connect
ttcp-t: 134217728 bytes in 20.29 real seconds = 6461.31 KB/sec +++
ttcp-t: 16384 I/O calls, msec/call = 1.27, calls/sec = 807.66
ttcp-t: 0.1user 10.3sys 0:20real 51% 0i+0d 0maxrss 0+2pf 13420+7165csw

ttcp-r: socket
ttcp-r: accept from 192.168.44.7
ttcp-r: buflen=8192, nbuf=16384, align=16384/0, port=5001  tcp
ttcp-r: 134217728 bytes in 15.20 real seconds = 8623.84 KB/sec +++
ttcp-r: 38522 I/O calls, msec/call = 0.40, calls/sec = 2534.54
ttcp-r: 0.1user 6.0sys 0:15real 40% 0i+0d 0maxrss 0+2pf 21221+2062csw

FWIW, here are what my early SMC card can do testing one direction
at a time.
ttcp-t: 134217728 bytes in 13.31 real seconds = 76.94 Mbit/sec +++
ttcp-t: 16384 I/O calls, msec/call = 0.83, calls/sec = 1230.97
ttcp-t: 0.0user 9.6sys 0:13real 73% 0i+0d 0maxrss 0+2pf 23052+612csw

ttcp-r: 134217728 bytes in 11.76 real seconds = 87.11 Mbit/sec +++
ttcp-r: 63366 I/O calls, msec/call = 0.19, calls/sec = 5390.54
ttcp-r: 0.1user 5.7sys 0:11real 49% 0i+0d 0maxrss 0+2pf 55732+483csw

I hear a lot of digs of the 'de' driver, yet for me it has always
performed *very* well.

-Andrew
-- 
-----------------------------------------------------------------
Andrew Gillham                            | This space left blank
gillham@whirlpool.com                     | inadvertently.
I speak for myself, not for my employer.  | Contact the publisher.