I asked:
>
> I have a pair of sparcstations in an application. One is connected
> to an FDDI network, the other node on the network is a DEC FDDI bridge
> the other sparcstation is connected to one of the ethernet ports on
> the bridge.
>
> There are no other devices on the network. (We are prototyping an
> application.)
>
> The application involves sending messages between the two machines.
> At the moment, we are seeing a rather lower throughput that we expected.
>
> On investigation, I found that the machine connected to the Ethernet is
> reporting a collision rate of approx 40% on outgoing packets. (I ran
> netstat -i 15 and saw 950 packets and 397 collisions.) The machine
> connected to the FDDI network reports zero collisions which is what
> is expected from this interface.
>
> From a random sample of other network segments around here, I have found
> figures of >900 packets and <10 collisions in the same (15 sec) time
> interval reported from other machines.
>
> Are there any interface tuning issues that I should address?
>
> Is this a common problem in mixed FDDI/Ethernet networks?
>
> Thanks, I shall of course post a SUMMARY:
>
> The various items referred to are:
>
> Two sparcstaion 5 machine running solaris 2.4.
> One DECSwitch 900EF.
>
> Regards John O'Connor
>
I received various suggestions mostly that I look at the cables
and connectors in case there was a problem there. An alternative
suggestion was that perhaps there were some packets on the net
of which I was not aware.
Thanks for that to:
mshon@sunrock.East.Sun.COM
tox@remarque.berkeley.edu
valdes@geosun.uchicago.edu
don@opensys.com
I checked these but the problem lay elsewhere. My computer was
just too fast. The application was sending a large block of data
to a socket in a single call. Unix was then breaking this up and
transmitting a series of packets to the other machine one after
the other. (These packets were of course all the maximum Ethernet
size of 1500 bytes.)
Now, at some stage after receiving the first packet or packets,
the receiving machine was trying to send a TCP ack. This was
whizzing around the FDDI to the bridge. The bridge would then
wait until the Ethernet was quiet. (The sender finishes
transmitting the next packet.) At that point, as soon as the
bridge detects that the net is quiet, it starts to transmit.
Meanwhile, the sender is ready with another packet and transmission
also commences as soon as the net is quiet. Guaranteed collision!
My solution was to change the transmitting code so that rather than
post one huge write to the socket, the system posts writes that will
fit into a single packet. In between these sucessive writes, the
application calls nanosleep to pause for 0.2 milli Seconds. This
routine was chosen because it is MT safe. This allows the receiving
system to get its acks back in the spaces between the messages.
Now I see 1 or 2 collisions where I used to see nearly 400.
I don't know how short we can make the pause between packets but the
current setting seems to work OK.
Regards John O'Connor
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:26 CDT