Interface collisions

[David Kelly]

On Mon, Mar 31, 2003 at 08:38:04AM -0600, Josh Paetzel wrote:
> On Mon, Mar 31, 2003 at 08:20:34AM -0600, Jack L. Stone wrote:
> > For the first time within the past few days, I've noticed collisions being
> > reported on the public NIC for one of the servers. I'm not sure if it means
> > the switch or the NIC is the culprit, so not sure which component may need
> > to be replaced.
> > 
> > Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
> > rl1   1500  <Link#2>    00:40:33:5b:bb:5f  6816063     0  7494432     0
> > 66977
[...]
> I'm lazy, I would replace the cable first.  If that didn't work I'd suspect 
> the $10 realtech card, and if that didn't work then I'd suspect a bad port on 
> the switch.

You would sweat over a number which says less than 1 in 100 packets sent
had to back off and requeue? No matter that "other machines with same
hardware/software don't accumulate collisions" I don't believe this
connection is broken.

Others have suggested hard setting the data rate and duplex on the NIC.
That is not a bad idea, especially when using less than premium
hardware.

Replacing the cable isn't a bad idea either. Often when a UTP cable is
wired incorrectly by not observing proper pairing of wires (honor the
Twisted Pair part of UTP) it mostly works but crosstalk between wire
pairs is more than it should. Enough to cause errors. I've seen machines
run for months wrongly wired until the position of the sun and moon are
finally unfavorable enough that the system falls off the net.

The sad thing is that 3Com NIC's tend to work thru the bad wire while
everything else I have fails immediately. That's both good and bad.
Would like to turn off the 3Com's added ability for initial installation
then turn it on for production as extra margin for dependability. But
now that I know, I bring my laptop for debugging the connection.

-- 
David Kelly N4HHE, dkelly at hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.