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@xxxxxxxxx> 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 -----
