ON THE WIRE / BILL ALDERSON AND J. SCOTT HAUGDAHL

Ethernet: Back To The Basics

Bill : Whoa. Before considering any major architectural changes, let's analyze what's really happening on the wire.

Scott : Right. Our analysis of the multiple segments did not indicate that collisions were causing any problems or delays. We did, however, make note of the fact that Cyclic Redundancy Check (CRC; also known as Frame Check Sequence or FCS) errors were present.

Bill : Aha, the dreaded CRC! The CRC is a 32-bit checksum appended to the end of every packet at the DLC (Data Link Control) layer to tell the receiver that the bits are really the ones that the sender meant to send. If the CRC calculated by the receiver does not agree with the one that comes with the packet, then one or more bits in the packet are bad, indicating a change in bits some where between the sender and receiver.

Scott : Setting our capture filter on bad frames allows us to capture only the CRC error frames, which will tell us the source and destination of the bad frames. Then we can set our capture filter on a given suspect source address, to see how many CRC frames there are in a given set of transactions and what impact the errors have on those transactions.

Bill : Since the user is reporting a wide fluctuation in response times, we suspect that the client(s) with the CRC errors are at the low end of the spectrum in terms of their file-transfer throughput.

Scott : In one instance during an application load, there were seven out of 240 frames with CRC errors from a workstation to a server, or about a 3 percent error rate. The throughput, as measured by our analyzer, was only 20 Kilobytes per second, very poor for a local Ethernet file transfer.

Bill : Further analysis confirmed what we see in many NetWare environments. Native NetWare Core Protocol (NCP) works on the principal of "implied" acknowledgments. For example, if a workstation never receives a response to a command, it re-sends the packet. Acknowledgments aren't required, since the data coming back is an implied acknowledgment that the command was received. If data is not received within a certain amount of time, then the command is re-sent. Since the original command packet contained a DLC CRC error, the receiving Ethernet adapter discards the packet, since the data inside the packet can't be trusted.

Scott : So, the effect is like a dropped packet; it could have been at a bridge, a router, somewhere in the internetwork or, in this case, simply dropped at the destination because of a CRC error.

Bill : Right. By default, the re-try time-out for the NetWare Core Protocol (NCP) is 10 ticks. A PC's clock ticks operate at the rate of 18.2 per second, making a 10-tick time-out delay of approximately .550 second s, or about half a second. So the seven CRC packets in our analysis were adding a 3.5 second delay to the file transfer for every 100 KB of data transferred.

Scott : To answer our customer's original question "Are Ethernet collisions bad?" generally speaking the answer is an empathetic no. As illustrated in the figure, collisions that occur in the first 512 bit times are re-transmitted by the (Ethernet) DLC layer, which is that chip on your Ethernet adapter.

Bill : Since this re-try is very fast, in the tens of microseconds, very little degradation is noticed.

Scott : On the other hand, dropped packets, such as the CRC error packets dropped by the receiver, must be retransmitted by a higher layer. This is typically the transport layer (there is no transport layer per se in native NetWare; in our example above, NCP performs many transport layer-like functions), which has a "long" time-out to allow for internetwork delays. Since NCP is considered an application-layer protocol we could call these application-layer time-outs.

Bill : Thus a 3 percent collision error rate (from a single station) will have little impact on network performance, whereas 3 percent CRC errors can bring a file transfer to its knees!

Scott : Errors are always relative to the workstation and network. For example, a network-wide three percent collision rate is more than tolerable, provided the collisions are randomly dispersed. On the other hand, if there is only one station generating more collisions than good packets, I would certainly take a look at that workstation!

Bill : So what's causing the CRC errors in this network?

Scott : We examined all the components in the system between the suspect workstation and the hub, and everything checked out, including the adapter and all the wiring up to the hub. Then we discovered that the hub was in turn connected to a multiport 10BaseT card plugged into a hub tha t housed a multiport bridge card. This bridge card was used to bridge the various Ethernet segments (hubs) together. As it turned out, the CRC errors were occurring between the multiport 10BaseT card and the suspect station that was attached to the hub. Once again, the wiring for this connection checked out. Directly connecting the suspect station's hub to an AUI connection at the multiport bridge card solved the problem.

Bill : So a little sleuthing and process of elimination pinpointed the problem.

Scott : Yup. When the problem was fixed, throughput on this, as well as other stations going through this hub, increased to over 600 KBps (and yes, there were still about the same amount of collisions occurring), and our customer was a lot happier.

So don't rearchitecture your network on account of a few percentage points of on-going collisions and take care of those CRC errors!

Bill : Hum... Going from 20 to 600 KBps, I'd be smiling too...

Bill and Scott are principals of the Pine Mountain Group and spend their time troubleshooting large networks, training end users in protocol analysis and developing tools to allow users to make better use of their protocol analyzers. They can be reached at otw@pmg.com.