Soft Collision Detection in the Sniffer Software Explained

To count a soft collision, the Sniffer must receive a valid preamble and a valid start frame delimiter. This is true for all normal Ethernet cards. If there isn't a preamble or start frame delimiter, it is impossible for us to receive a frame and it is impossible to look for a soft collision without a frame. But, this is also true for almost all of our competitors and true for all RMON products that I know of.

Most competitors will count a collision for any frame that is 60 bytes or less, and has a CRC error. Thus, all CRC errors for frames 60 bytes or shorter are considered collisions. CRC errors in frames longer than 60 bytes are considered just normal CRC errors. In fact, you can show this with the Sniffer Traffic Generator. Load a single frame into the buffer from a trace file, and delete bytes from the end until the frame is 60 bytes long. Use Frame Edit under Display to set this frame as a CRC error. Now, use Buffer Mode Traffic Generation to continuously generate this frame. The Sniffer will transmit that one frame with a bad CRC. Products like the Azure analyzer will count tons of collisions, even though the Sniffer is the only generator on the wire.

We decided to add one additional test to decide about a collision. Some of our engineers at NGC worked on Ethernet chipsets in the past. To our knowledge, all Ethernet chipsets send a pattern of alternating one's and zero's as the "JAM" signal. Technically, according to the 802.3 spec, there is no defined JAM signal. The spec just says that the transmitting station must continue to transmit at least one "slot time" (which is 60 bytes), and then must guarantee that the frame has a CRC error. So, in theory, a board could just continue to transmit the frame data and then put a bad CRC on the frame. But, in reality, our engineers know that almost everyone that produced an Ethernet chipset will send a pattern of alternating one's and zeros. They will also put alternating one's and zero's into the CRC bits. The Sniffer soft collision detection looks for either AAAA or 5555 to be in the last 16 bits of the CRC field. If we do not see either AAAA or 5555, then we call the frame just a normal CRC error. If we do see AAAA or 5555 in the last 16 bits of the CRC, and the board reports that the frame has a bad CRC, then we call it a collision.

So, if you run the same Sniffer traffic generator test, and receive the data using both an Azure analyzer and a Sniffer notebook, the Azure will mistakenly count collisions, while the Sniffer will count them as CRC errors. The only way for a Sniffer to count collisions is if the last 16 bits of the CRC pattern is either 5555 or AAAA.

For you technical junkies, this does create one hole. If a frame is really just a CRC error, and if the frame data along with the error happens to create a CRC that ends in either AAAA or 5555, then the Sniffer will "mistakenly" count a true CRC error as a collision. But this "mistake" can only happen in 2 out of 65,535 chances. Also, the card MUST report a frame as a CRC error before we do a "collision" test. So it is impossible for us to count a good frame as a collision even if the good frame ends in either format. (5555 or AAAA.)

By the way, in the next release of the Sniffer we may change the counters to better detect "late collisions". We could enhance our soft collision detection to only count collisions if the frame is 60 bytes or shorter. If the frame is longer than 60 bytes, and there is a CRC error, and the CRC ends with 5555 or AAAA, then it is probably a late collision. We are thinking about making this a separate counter, to help quickly detect late collisions. We may even add a specific "late collision" counter to the screen.