From owner-freebsd-stable Wed Apr 15 13:23:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA01424 for freebsd-stable-outgoing; Wed, 15 Apr 1998 13:23:08 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA01211 for ; Wed, 15 Apr 1998 20:22:18 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id QAA24581 for ; Wed, 15 Apr 1998 16:22:14 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id QAA12351 for ; Wed, 15 Apr 1998 16:22:11 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id QAA00253; Wed, 15 Apr 1998 16:22:10 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Wed, 15 Apr 1998 16:22:10 -0400 (EDT) Message-Id: <199804152022.QAA00253@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-stable@FreeBSD.ORG Subject: various PCI Ethernet cards v.s. SMC Ethernet switches.... X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-stable@FreeBSD.ORG Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk 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 Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message