From owner-freebsd-hardware Wed Aug 23 11:47:16 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA17650 for hardware-outgoing; Wed, 23 Aug 1995 11:47:16 -0700 Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id LAA17643 for ; Wed, 23 Aug 1995 11:47:10 -0700 From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id TAA19235 for freebsd-hardware@freebsd.org; Wed, 23 Aug 1995 19:46:36 +0100 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Wed, 23 Aug 95 19:46:23 +0100 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Wed, 23 Aug 95 18:46:20 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Wed, 23 Aug 95 18:46:20 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:19591-950823184620-7B40] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: freebsd-hardware@freebsd.org Date: Wed, 23 Aug 95 18:46:20 +0000 Content-Identifier: Performance prob Message-Id: <"MAC-950823194610-09D3*/G=Andrew/S=Gordon/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS> To: freebsd-hardware@freebsd.org Subject: Performance problem with SMC 10/100Mb Ethernet cards Sender: hardware-owner@freebsd.org Precedence: bulk Since SMC are currently offering a cheap deal on an 'evaluation kit' containing two EtherPower 10/100 adaptors and a crossover cable to connect them, I ordered one to try out. The results so far are not encouraging: My test setup is: +--------------+ +----------------+ | P90 PCI | | 486DX4/100 PCI | +--------------+ +----------------+ | | crossover cable (100baseTX) | main ethernet (10base2) | ----------------------------------------- ------------------------+------- Both machines are running 2.0.5R(*). The main ethernet and the two-station network are addressed as two separate class C networks. The second interface in the Pentium box is an SMC Etherpower 10. The Pentium box is a made-by-intel Triton-based motherboard. I have tried two different 486 machines, one made-by-intel motherboard and SCSI discs, one Taiwanese (Gigabyte?) motherboard with IDE disc, with the same results. My basic test is FTP-ing a large file (eg. kernel.GENERIC) between the two systems. Problems: 1) When operating at 100Mb/sec, there seems to be substantial (random) packet loss going from the Pentium to the 486. When you fluke an error-free transfer throughput of about 2Mbyte/sec is achieved, but more commonly there are pauses of a second or so giving a net througput of only 300kbyte/sec typically. If configured for 10Mb/sec (ifconfig de0 -link2), a consistent throughput of 1Mbyte/sec is observed, with no pauses. Similar pauses are also noticable using telnet, and also if the 486 is re-booted to Windows, accessing a Samba server on the Pentium box. 2) Regardless of the interface speed, an FTP transfer from the 486 to the Pentium runs smoothly (fast) if the FTP connection was made to the address of the 10/100 interface in the Pentium box, but if the address specified was that of the other interface in the same machine, throughput starts slow but gradually speeds up, reaching full speed after about 25Kbyte. In an attempt to eliminate the one piece of hardware I could replace, I changed the SMC-supplied cat5 UTP cable (with RJ45 connectors) by a homemade cable using IBM type1 cable and DB9 connectors, using the other connector on the cards. My homemade cable appeared to work a bit better for problem 1, but by no means eliminated it (so the difference may be experimental error). Since others have reported good things with these cards, I must be doing somthing wrong. Do I have a hardware fault, FreeBSD driver problem, or is 100Mb/sec just too fast for 486DX4/100 boxes? Any ideas appreciated..... Andrew. ----- (*) initially tested with pure 2.0.5R. I subsequently checked the driver in -current, which had changed very slightly, so built a 2.0.5R kernel with the de driver out of -current. No change.