collisions 200% of Tx on 10BaseT (21140, .90q, Samsung , SC1200-TX)

[Donald Becker]

On Mon, 26 Apr 1999, Monty wrote:

> As it turns out, the collisions occur only between the machines on my
> network using Xircom CEM 10/100 adapters and the Tulips.  Other cards
> on the network have no collision problems talking to the Tulips.
> Thus, this does not seem to be a Tulip problem.

Check the duplex on the Xircom side.  As I recall, there is something wierd
with the Xircom autonegotiation.  (Beyond the effect that the Xircom driver
freezes the machine for 3 seconds while it's doing media detection.  Hey,
it's easier to write a driver if you assume that your code is the most
important thing the machine runs!)

> I also bought a bunch of other Tulips to try this out with (they're
> cheap, it's my budgeted hobby ;-) and all exhibit the same behavior
> talking to the Xircoms.  The Xircoms can talk to any other machines on
> the net without trouble.

Two theorys to check:
   The Tulip driver collision counter is "all collisions", not a just
    "had at least one collision on this packet".
   The Xircom is too aggressive when retransmitting after a collision

I enable the "capture effect resolution" feature in the Tulip chips.  It's a
special deference mode that avoids the Ethernet capture effect, where the
current transmitting host has higher priority during during the next
transmit attempt.

This feature is very beneficial to overall network performance.  But it
causes the "good" hosts to lose to aggressive hosts.  This used to be a big
deal when cheating on the spec resulted in wins for trival benchmarks.  But
using tests like 'ttcp' show aggressive hosts for what they are -- overall
losers.

> I did notice one thing when pinging the Tulip-bearing server from the
> Xircom-powered notebooks; the first (three?  My memory is a bit fuzzy
> as I write this) pings are about 2ms; after that, pings drop into the
> serious sub-millisecond range.  Happens every time I do it.  Could
> either the Tulip or Xircom driver be 'pulling out all the stops' after
> the first few packets, not allowing the other side to ack?  Actually,

The 'ping' program won't show duplex or collision problems.  That makes it
an excellent "does something" test, but not bad "works correctly" test.

> looking at this, it seems logical that it would be the Xircom driver
> doing this, not the Tulip.
...
> Donald; I realize now that this is not a Tulip driver bug.  Does the
> delay issue seem like a plausible thing to ping the Xircom driver
> author about?  

Yes.
This may actually be a feature -- an effect of dynamic interrupt mitigation.
Except for the recent discussion about the need for usleep(2)  after the
transmit demand, the Tulip driver shouldn't have a transmit issue.

Donald Becker					  becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882	     http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html