Date: Wed, 15 Apr 1998 16:22:10 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-stable@FreeBSD.ORG Subject: various PCI Ethernet cards v.s. SMC Ethernet switches.... Message-ID: <199804152022.QAA00253@brain.zeus.leitch.com>
next in thread | raw e-mail | index | archive | help
Does anyone out there have any experience using FreeBSD-stable (2.2.x
cvsup'ed March 31 to be exact) or something reasonably similar with
10/100 Ethernet switches, particularly the SMC EZ switch?
We're seeing some exceptionally weird (and bad) behaviour from at least
the de driver, and sometimes the tx driver too.
We have an SMC EZ-Switch 8+2 (6408TT), which is unfortunately a very
dumb and unmanaged switch (no knobs, few lights, and no stats reports).
It's a "store-and-forward" device with error detection, and with a
"non-blocking design that allows simultaneous wire-speed transport of
multiple packets at consistently low latency." (It also does automatic
address learning, but that's not really relevant here....) [FYI our
primary desire for such a switch is as a security device to prevent
snooping of traffic between the low-bandwidth servers on each port.]
The Ethernet cards we've tested with are the dual port SMC 9332 BDT, the
single port SMC 9332 BVT, the single port SMC 9432 TX, and an Intel
EtherExpress Pro 10/100B Ethernet (fxp driver).
The target host is on the other side of the switch from the test host,
and is on a 100baseT switch port and hub:
TEST ---- [10baseT]EZ6408[100baseT] ---- 100baseT-HUB ---- TARGET
The de driver will receive reasonably well in half-duplex mode
(i.e. with ftp you can get a file [~900-1000KB/s] but not put it [so
slow TCP eventually gives up]). When trying to put we get *lots* of CRC
errors, some alignment errors (both on input), and about a 50% collision
rate. 'Ping -f' shows 3-20% packet loss in both directions (normal
56-byte packets, and bigger packets won't work). There are also some
strange differences between autoselect and explict "media 10baseT/UTP
-mediaopt full-duplex".
The de driver won't reliably go to full duplex mode on the initial
ifconfig (usually hangs the card in such a state that it thinks it's at
100baseT4 even though the driver thinks it's at 10baseT/UTP, and the
switch shows a constant receive light).
Once I convince the de driver to switch to full-duplex mode and plug it
into a switch port that's configured for full duplex then it also works
reasonably well (though there are those strange pauses in traffic) for
transmission, but not at all for reception (with similar errors and
stats).
Now I happen to know that NetBSD-current recently introduced some fixes
to their version of the de driver from Matt and some CRC problems with
at least one variety of hardware seem to have been fixed (NetBSD v1.66).
The pre-2.2.6 tx driver didn't work at all with the switch, but now the
tx driver works a wee bit better than the de driver. It'll switch more
reliably to full-duplex mode. There's also about 3-20% packet loss with
ping -f in both directions. It'll receive just fine (full speed ahead
at about 800-900KB/s in both FD and HD). It'll transmit OK for short
streams in half-duplex mode, but more than about 8MB causes it to fail.
Transmitting in full-duplex mode it behaves much the same as the de,
though it seems as though it may eventually finish the 100MB file [it's
getting around 20KB/s, and didn't die after about 4MB].
We hadn't tried the Intel (fxp) card until today, so don't know if
there's any recent change in it. It behaves similarly to the tx driver,
though a wee tiny bit better speed-wise (in both directions, but still
abysmal in sending) in full-duplex mode, and dies much faster [about
2MB]. It is yet again even better in half-duplex mode, but still
abysmal in sending [50KB/s?, also dead after 2MB].
One interesting thing about all of these cards is that I see an almost
constant collision light on the switch when transmitting or receiving in
half-duplex mode.
All in all the tx driver is now the best, but is still effectively
unusable.
I can't quite imagine this is a problem with the switch -- otherwise
people wouldn't recommend them or use them. Though I can't prove this,
I'd guess that SMC's own (i.e. MS-Windows) drivers must work with their
own switch.
--
Greg A. Woods
+1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804152022.QAA00253>