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 - [EMAIL PROTECTED] - [EMAIL PROTECTED] ________ __ ____
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
