Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Jul 1999 14:46:28 +0200 (SAT)
From:      Reinier Bezuidenhout <rbezuide@oskar.nanoteq.co.za>
To:        vince@venus.GAIANET.NET (Vincent Poy)
Cc:        jmb@hub.FreeBSD.ORG, sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG
Subject:   Re: poor ethernet performance?
Message-ID:  <199907191246.OAA29203@oskar.nanoteq.co.za>
In-Reply-To: <Pine.BSF.4.05.9907190135380.331-100000@venus.GAIANET.NET> from Vincent Poy at "Jul 19, 99 01:39:53 am"

next in thread | previous in thread | raw e-mail | index | archive | help
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 <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

Reinier



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?199907191246.OAA29203>