Re: collision in the network card

[Chad Dailey <wireshark () thedaileyplanet com>]

Karthik--

I've learned over many years that collisions are very nearly irrelevant to
meaningful troubleshooting of performance problems.  The backoff and
reassertion of carrier/preamble happens very quickly, even after multiple
collisions, and only causes a negligible change in performance.  In many
cases, the change in performance disappears in comparison to jitter
measurements.  If you've got SNMP performance counters on your network gear
that show collision counters reaching more than six or seven (15 is the
upper limit before a transmission is aborted for a frame), then it might be
worth looking at a bit more closely.  In most of the cases where multiple
collisions occur (where more than one collision occurs for the attempted
transmission of a single frame), I have found that someone has changed the
interframe gap to a value lower than the Ethernet specification allows for,
which causes 'fairness' issues.  This was common practice in the 90's to
inflate throughput ratings for NICs.

That said, "late collisions" are another story entirely and are very
important in diagnosing a bad connection.  If the link propagation delay
from one station to the farthest away from it is longer than 64 bit times,
late collisions will often be the result, and quite evident on a busy
network.  Late collisions result in an abort of transmission for the frame
and expect the upper layer protocols to handle retransmission, which can
cause TCP to back off to a very slow rate if the problem persists.  Late
collisions are often also an indicator of a duplex mismatch on a link,
accompanied by CRC or FCS errors.

In full duplex ethernet, the collision detect mechanism is disabled, as the
connection is assumed to be a point-to-point link with private transmit and
receive channels.  Simplistically, CSMA/CD becomes CS, as there is no
multiple access of a link other than both ends of the link, no collision
detect, and even the carrier sense part is reduced to the simple assertion
of link state.  If you've got collisions in a full duplex environment,
something is definitely broken, and more often than not the first place to
look is autonegotiation failure.

After all that... I don't know of any way to use Wireshark to generate
meaningful information for link issues with commodity hardware, I find SNMP
counters on capable network equipment to be infinitely more useful for that
task.  There is lots of used gear that can be bought at a discount that will
help you get this information if you don't have it in place already.

Good luck,
Chad



On Sat, Feb 20, 2010 at 6:10 AM, ademar fey <ademar.fey () gmail com> wrote:

> Hi Karthik,
>
> yes, the idea is to check the number of the collisions ocurring in the lan
> in a general way, using wireshark or similar monitor software.
>
> Tks in advanced
>
> Ademar
> ----- Original Message -----
> From: "Karthik Balaguru" <karthikbalaguru79 () gmail com>
> To: "Community support list for Wireshark" <wireshark-users () wireshark org>
> Sent: Friday, February 19, 2010 4:37 PM
> Subject: Re: [Wireshark-users] collision in the network card
>
>
> > On Fri, Feb 19, 2010 at 10:58 PM, ademar fey <ademar.fey () gmail com>
> wrote:
> > > Hi all,
> > >
> > > is there any way to detect collision in the network card that is
> > > capturing
> > > packets to wireshark ??
> >
> > Do you want to check packets that convey collision handling
> > possibility/collision occurance in either receiver or transmitter ?
> >
> > Karthik Balaguru
> ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org
> >
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >
> > mailto:wireshark-users-request () wireshark org?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe