Prevent network packet collisions by adjusting conflicting interframe gap settings

Your 100-Mb network should be blazing along, but users complain that it's slow. Mismatched interframe gap settings among the network adapters could be the problem. Learn how to fix it by adjusting the TCP/IP protocol and interframe gap settings.

Are you not getting the performance you’d expect from a network running at 100 Mb, even though you're using 100-Mb network adapters with TCP/IP as your network protocol? If so, 100-Mb network adapters not adhering to the IEEE 802.3 specification for Ethernet networks could be the cause for this slip in performance. The IEEE 802.3 specification calls for a 96 bit times interframe gap between the time the adapter switches from transmit mode to receive mode.

When adapters that adhere to this specification are used on the same network with adapters that don’t, timing problems occur that eventually cause collisions on the network. This problem is compounded on networks that use the TCP/IP protocol because of the scheme it uses for acknowledging the receipt of data packets. In this Daily Drill Down, I’ll explain how you can solve this problem by adjusting the interframe gap settings and the way that the TCP/IP protocol works with Windows 2000 Professional and Windows XP Professional clients.

The interframe problem in a nutshell
The IEEE 802.3 specification calls for a 96 bit times interframe gap. Basically, this interframe gap is a period of silence between the moment a particular station sends a data packet across the network and the time that the other station responds. For a 100-b network card, this 96 bit times interframe gap comes out to 960 nanoseconds.

For the sake of comparison, the 96 bit times interframe gap is 9.6 microseconds for a 10-Mb network card, 96 nanoseconds for a 1-Gb network card, and 9.6 nanoseconds for a 10-Gb network card.

The interframe gap is designed to give the adapters involved in the communication time to switch from transmit mode to receive mode. In other words, once a network card has transmitted a data packet, the card needs a few nanoseconds before it is ready to receive a response.

When it comes to the speed of today’s computer technology, you may think that 960 nanoseconds is a long time—and it is. However, when the specification was first hammered out, using a formula based on 96 bit times was necessary for the network cards of the day to properly switch from transmit mode to receive mode.

While the 96 bit times interframe gap rule has remained set in stone, network cards have continued to evolve as the technology has improved and network speeds have increased. As such, the newer 100-Mb cards no longer actually require a 96 bit times interframe gap to switch from transmit mode to receive mode.

Considering this, some 100-Mb network card manufacturers are ignoring the standard and configuring their products with a much smaller interframe gap in order to pump up the data transfer rate. However, other 100-Mb network card manufacturers are continuing to adhere to the 96 bit times standard.

If you're using 100-Mb network cards from the same manufacturer in all the systems on your network, you’ll be fine. But a more common scenario is an organization that uses 100-Mb network cards from multiple manufacturers. Thus, if you administer in this type of configuration, it's possible your network is suffering due to an inordinate amount of network collisions caused by differing interframe gap settings.

The TCP/IP headache
While the differences in the interframe gap settings is a big enough performance problem to deal with, it can get worse when you’re using TCP/IP as your main protocol.

The TCP/IP protocol specification calls for sending an ACK (acknowledgement) for every two data packets that a network station receives. If the network cards in the two systems are using different interframe gap settings, it’s possible that a network station that has received two TCP/IP data packets could be sending its ACK at the same time the sender station is sending another data packet. This would compound the network collision problem already initiated by the mismatched interframe gap settings.

Use a protocol analyzer to detect collisions
If you’re encountering network performance problems, you can easily test your network with a protocol analyzer, or a similar device, to measure collisions, runt packets, or CRC (cyclic redundancy check) errors. Keep in mind that under regular operating conditions, some collisions are normal. However, a high percentage of collisions, runt packets, or CRC errors indicates a serious performance problem that could very well be related to the differing interframe gap settings of the various network cards on your network.

Adjusting interframe gap settings
To begin with, you need to have on hand a list of all the brands and versions of 100-Mb network cards installed on your network. (This is where a network inventory will come in very handy). Next, check the network card documentation for a specification on the interframe gap setting. If need be, contact the manufacturer directly, or via the company's Web site, to track down the interframe gap setting. You’ll also want to find out if the network card provides a method of adjusting the interframe gap setting.

The goal here is to have all the cards on your network use the same interframe gap setting. So, if those cards that have nonstandard interframe gap settings provide a mechanism of adjusting the setting, you’ll want to bring them in line with all of the other cards on your network.

Other terms
As you’re searching for information relating to your specific network card’s interframe gap setting, keep in mind that this setting has several aliases. Some manufacturers call it the interframe space or inter-frame space. I’ve also seen it referred to as the interpacket gap. In addition, it goes by the acronyms IFG, IFS, and IPG.

Adjusting the TCP/IP protocol
You can also alleviate the problem by adjusting the way the TCP/IP protocol works. As I mentioned, the default configuration for the TCP/IP protocol calls for sending an ACK for every two data packets that a network station receives, which can cause a higher volume of network collisions on a network using network adaptors with mismatched interframe gap settings. The adjustment I’ll explain here will configure the TCP/IP protocol to send an ACK for every data packet received. To do so, you’ll need to edit the registry and add a special parameter called the TcpWindowSize to the TCP/IP key.

Since editing the registry can be dangerous, you might want to consider performing a full backup before you attempt this operation.

To begin, select the Run command on the Start menu and launch the Registry Editor by typing regedit.exe in the Open text box. Once you have the Registry Editor up and running, locate and double-click on the key HKEY_LOCAL_MACHINE. When this subtree is visible, open each of the following subtrees in succession:
  • CurrentControlSet
  • Services
  • Tcpip
  • Parameters

After opening the Parameters key, pull down the Edit menu and select New | DWORD Value. Then, assign the new value the name TcpWindowSize and press [ENTER] twice. When you see the Edit DWORD Value dialog box, type 2920 in the Value Data text box. Finally, select the Decimal option in the Base panel. Your system is now set to send an ACK with every data packet received.

Keep in mind that adding this TcpWindowsSize parameter to the registry can degrade network performance for Wide Area Networks (WANs) because there is already some extra latency introduced by this type of connection.

When you use 100-Mb network adapters from various manufacturers and are using TCP/IP as your network protocol, you might not be getting the performance you’d expect from a network running at 100 Mb due to mismatched interframe gap settings. In this article, I’ve explained how to solve the problem by tracking down information on your network cards' interframe gap settings and how to adjust the setting, if needed. In addition, I’ve explained how to alleviate the problem by adjusting the way the TCP/IP protocol works.



Greg Shultz is a freelance Technical Writer. Previously, he has worked as Documentation Specialist in the software industry, a Technical Support Specialist in educational industry, and a Technical Journalist in the computer publishing industry.

Editor's Picks