High Rate of Collisions on 100-Megabit Networks (169789)


The information in this article applies to:

  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows NT Workstation 3.51
  • Microsoft Windows NT Workstation 4.0
  • Microsoft Windows NT Server 3.51
  • Microsoft Windows NT Server 4.0
This article was previously published under Q169789
IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

SYMPTOMS

You may notice slow network performance while copying files when you are using the TCP/IP protocol with a 100-Megabit network adapter. You may experience this degraded performance while you are using Windows Explorer in Windows NT 4.0 or Windows 2000 or the Copy command from a command prompt in Windows NT 3.51. Performance is normal when using File Manager in Windows NT 3.51.

Note: Although the slow performance has been observed on several 100-Megabit network cards, this problem is not specific to Windows.

CAUSE

The slow network performance is due to a high rate of early collisions on the network. The interframe gap, the amount of time a workstation waits before attempting to transmit on the wire, is lower than the IEEE 802.3 specification of 9.6 microseconds.

RESOLUTION

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
  • To resolve this issue, contact your network adapter manufacturer for information about increasing the interframe gap. Intel EtherExpress 100B adapters have a registry parameter that controls the interframe gap. To modify this parameter, use the following steps:

    1. Start Registry Editor.
    2. Locate the following registry key:
      
         HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ 
         Services\e100b<x>\Parameters
      where <x> is the number of your interface card.
    3. Click Edit, click Add Value, and then type the following information:

      Value Name: Adaptive_ifs
      Value Type: REG_DWORD
      Data: 1 (enable adaptive algorithm)

      By default, the adaptive algorithm to detect collisions and tune the interframe gap is enabled. If you set the Data value to 0, you disable the adaptive algorithm. A value between 2 and 200 sets a predefined interframe gap. Measure collisions with this parameter set to intervals of 20 decimals (starting at 20), and select a value that has a low collision rate and does not affect performance.
  • To work around this issue, you can tune the TcpWindowSize registry parameter so that the sender must wait to receive an ACK from the receiver before sending more data. This prevents collisions.

    The TcpWindowSize parameter typically does not exist in the registry, so you must create it. To do so, follow these steps:
    1. Start Registry Editor.
    2. Locate the following registry key:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Tcpip\Parameters

    3. Click Add, click Value, and then type the following information:

      Value Name: TcpWindowSize
      Value Type: REG_DWORD
      Data: 2920 (decimal) - Number of bytes. Set this value to Decimal 2920 for Ethernet networks and two times the maximum TCP data size on other networks. However, you do not have to modify this setting for other networks because Token Ring, FDDI, and others, do not have collisions as Ethernet does.

      Note: If you modify this parameter, you may significantly affect performance. Generally, on a WAN network or a regular 10-Megabit network, depending on the topology, there will be some latency between the sender and the receiver. Therefore, TCP/IP ACKing behavior does not create collisions. Tuning TcpWindowSize in this case will only reduce throughput.
For additional information about TCP/IP, please see the following white paper available on the Microsoft anonymous FTP server:

File Name: Tcpipimp2.doc
Location : ftp://ftp.microsoft.com/bussys/winnt/winnt-docs/papers/
Title : "TCP/IP Implementation Details"

MORE INFORMATION

A "collision" occurs when two stations transmit simultaneously on the wire. An "early collision" is any collision that occurs before 512 bits of the frame have been put onto the wire. Early collisions may occur regularly in a normally operating Ethernet network. There is no hardware malfunction or misbehaving station.

The IEEE 802.3 specification states that, before a station can attempt to transmit on the wire, it must wait 9.6 microseconds (interframe gap). Several adapter manufacturers have designed their cards with a smaller interframe gap to achieve higher data transfer rates, which could lead to a high rate of collisions.

This problem can be influenced by the behavior of the upper layer protocol. The TCP/IP specification indicates that an ACK should be sent for every other frame received. That is, when a TCP host receives two data frames, it should then transmit an ACK to the sender. The potential for collisions to occur is high when a client that has received two packets tries to send an ACK while the sender may be trying to send more data to the client.

Analysis of Windows NT 3.51 File Manager File Copy

Under Windows NT 3.51, when you are copying files using File Manager, the redirector performs only 4KB reads. The pattern of data transfer is shown below, as captured using Network Monitor: 
18 CLIENT SERVER  SMegabit   C read & X, FID = 0x804, Read 0x10c5
19 SERVER CLIENT  SMegabit   R read & X, Read 0x10c5
20 SERVER CLIENT  NBT   SS: Session Message Cont., 1460 Bytes
21 SERVER CLIENT  NBT   SS: Session Message Cont., 1437 Bytes
22 CLIENT SERVER  TCP   .A...., len:    0, seq:585361-5851029

At the TCP level: 
Frame 18: TCP: len:   64, seq: 585297-585360, ack:734154,
>Client sends 64 bytes of data (SMegabit Command to read 4KB);

Frame 19: TCP: len: 1460, seq: 734154-735613, ack:585361,
>Server then sends back 1460 bytes of data (smb response + data), with a
piggybacked ACK indicating that it received all the data in frame 18.

Frame 20: TCP: len: 1460, seq:    735614-737073, ack: 585361,
Frame 21: TCP: len: 1437, seq:    737074-738510, ack: 585361,
>Server then sends two more data frames and completes the 4KB transfer.

Frame 22: TCP: len:    0, seq:    585361-585361, ack: 738511,
>Client sends an ACK for all the data that it received on these two frames.

Because the server has completed the 4-KB data transfer, it has no more data to send. Therefore, potential for collision to occur does not exist.

Analysis of Windows NT 4.0 and Windows 2000 Windows Explorer File Copy

When the same file copy is initiated using a command prompt, or using Windows Explorer in Windows NT 4.0 and Windows 2000, the pattern of data transfer is different. In this case, the redirector issues a 60KB "bulk read" or "raw read" (Windows NT 3.51). The data transfer pattern is shown below: 
10 CLIENT SERVER  SMegabit C read & X, FID = 0x1004, Read 0xf000
11 SERVER CLIENT  SMegabit R read & X, Read 0xf000
12 SERVER CLIENT  NBT SS: Session Message Cont., 1460 Bytes
13 SERVER CLIENT  NBT SS: Session Message Cont., 1460 Bytes
14 SERVER CLIENT  NBT SS: Session Message Cont., 1460 Bytes
15 SERVER CLIENT  NBT SS: Session Message Cont., 1460 Bytes
16 CLIENT SERVER  TCP .A...., len: 0, seq:404791-404791, ack
17 CLIENT SERVER  TCP .A...., len: 0, seq:404791-404791, ack
18 SERVER CLIENT  NBT SS: Session Message Cont., 1460 Bytes
19 SERVER CLIENT  NBT SS: Session Message Cont., 1460 Bytes
20 SERVER CLIENT  NBT SS: Session Message Cont., 1460 Bytes

At the TCP level: 
10 CLIENT SERVER  TCP len:   64, seq: 404727-404790, ack:   6992081
>Client sends 64 bytes of data (SMegabit command to read 4KB);

11 SERVER CLIENT  TCP len: 1460, seq: 6992081-6993540, ack:    404791
>Server sends the piggy back ACK, and the SMegabit response with some data;

12 SERVER CLIENT  TCP len: 1460, seq: 6993541-6995000, ack:    404791
13 SERVER CLIENT  TCP len: 1460, seq: 6995001-6996460, ack:    404791
>Server sends rest of the data to the client.

>**Collision likely at this point, because the client will try to send an
ACK.

14 SERVER CLIENT  TCP len: 1460, seq: 6996461-6997920, ack:    404791
15 SERVER CLIENT  TCP len: 1460, seq: 6997921-6999380, ack:    404791
>But server is able to get the wire and send more data.

16 CLIENT SERVER  TCP len:    0, seq: 404791-404791, ack:   6996461
>Client is able to get the wire and send the ACK for data on frames 12 and
13.

17 CLIENT SERVER  TCP len:    0, seq: 404791-404791, ack:   6999381
>Client is able to get the wire and send the ACK for data on frames 14 and
15.

18 SERVER CLIENT  TCP len: 1460, seq: 6999381-7000840, ack: 404791
19 SERVER CLIENT  TCP len: 1460, seq: 7000841-7002300, ack: 404791
>Server continues to send data.

>**Collision likely at this point, because the client will try to send an
ACK.

20 SERVER CLIENT  TCP len: 1460, seq: 7002301-7003760, ack: 404791
>But server is able to get the wire and send more data.

As mentioned earlier, when you use the TCP/IP protocol, TCP ACKing influences the collision. However, the problem is not due to TCP/IP or the enhancement for Windows Explorer to do 60KB bulk reads. The problem can be illustrated using FTP also. TCP/IP, the redirector, and Windows Explorer have absolutely no control over interframe gap. Interframe gap is at the physical layer, which is controlled by the chipset on the adapter. If you experience a high rate of collisions, please contact your network card vendor.
Modification Type:MajorLast Reviewed:6/3/2003
Keywords:kbnetwork KB169789
©2002 Microsoft Corporation. All rights reserved.