Date: Mon, 19 Jul 1999 13:41:28 -0700 (PDT) From: Vincent Poy <vince@venus.GAIANET.NET> To: Reinier Bezuidenhout <rbezuide@oskar.nanoteq.co.za> Cc: jmb@hub.FreeBSD.ORG, sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? Message-ID: <Pine.BSF.4.05.9907191335400.331-100000@venus.GAIANET.NET> In-Reply-To: <199907191246.OAA29203@oskar.nanoteq.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: > 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. Hmmm, the thing is we replaced the cables with pre-made ones that go directly from the machines to the Cisco Catalyst 2924XL switch. Ofcourse, the switch is on 10/100 Auto-negotiation. > 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. I was using ttcp in two separate instances, one for send and one for receive between the same two machines. I did ttcp -r -s and the other end was ttcp -s -r. > Also check with "netstat -sn" to see if there are any other counters that > increase with the full-duplex transfers. Will do that. > > > 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". I thought from a fxp to a fxp, you will need a x-over since a straight-wire won't work. > > > 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 <nice large number> -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 Ah, I guess you didn't test it on a actual network that's connected to the world and also it was a direct connection between the machines rather than through a switch that can be congested. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9907191335400.331-100000>