Wireshark-users: Re: [Wireshark-users] collision in the network card
From: Chad Dailey <wireshark@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 20 Feb 2010 08:38:15 -0600
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
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 -----
From: "Karthik Balaguru" <karthikbalaguru79@xxxxxxxxx>
To: "Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
- References:
- [Wireshark-users] collision in the network card
- From: ademar fey
- Re: [Wireshark-users] collision in the network card
- From: Karthik Balaguru
- Re: [Wireshark-users] collision in the network card
- From: ademar fey
- [Wireshark-users] collision in the network card
- Prev by Date: Re: [Wireshark-users] collision in the network card
- Next by Date: [Wireshark-users] performance analysis with wireshark
- Previous by thread: Re: [Wireshark-users] collision in the network card
- Next by thread: [Wireshark-users] performance analysis with wireshark
- Index(es):