From owner-freebsd-hackers Mon Jul 19 5:45:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [196.37.91.10]) by hub.freebsd.org (Postfix) with ESMTP id 14E9E1513D; Mon, 19 Jul 1999 05:45:14 -0700 (PDT) (envelope-from rbezuide@oskar.nanoteq.co.za) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.9.0/8.9.0) id OAA29203; Mon, 19 Jul 1999 14:46:28 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199907191246.OAA29203@oskar.nanoteq.co.za> Subject: Re: poor ethernet performance? In-Reply-To: from Vincent Poy at "Jul 19, 99 01:39:53 am" To: vince@venus.GAIANET.NET (Vincent Poy) Date: Mon, 19 Jul 1999 14:46:28 +0200 (SAT) Cc: jmb@hub.FreeBSD.ORG, sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi .. > > 1. If you want to test the network speed ... use ttcp or something > > that generates the data and doesn't read it from disk. > > ttcp works. The only problem is when I tried it in both > directions, at once. the total becomes 11.xMbytes/sec total as opposed to > 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. But ... what it rather seems like .. is that the devices are not in full-duplex mode .... generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with "netstat -in". If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. Also check with "netstat -sn" to see if there are any other counters that increase with the full-duplex transfers. > > 2. When doing full-duplex and using fxp cards, stay away from X-over > > cables ... use a full-duplex switch etc. ... the fxp cards are not > > made to work with X-over cables (as far as I know - ala Intel spec) > > note ... only for full-duplex tests. > > Does anyone actually use X-over cables for 100Mbps Full Duplex > since 3Com said CrossOver cables are not rated for 100Mbps or something > even though it's Cat5. Actually, in the older Intel docs for the Pro100B, > it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of "device timeouts". > > We have done tests in full-duplex with non Intel cards (because we did > > not have a switch at that time :)) and with max size packets we got around > > 188.00 Mbps using the de0 driver. > > Pretty interesting. How did you do the full duplex tests? > I'll describe the setup briefly ... :) We had 3 machines .... two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... --------- ---------- --------- | Gen 1 |-----------------| Router |-------------| Gen 2 | --------- ---------- --------- Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that "does not exist". The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the "non existing" machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Reinier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message