High Rate of Collisions on 100-MB Networks

• Microsoft Windows NT Workstation versions 3.51 and 4.0
• Microsoft Windows NT Server versions 3.51 and 4.0

IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.

SYMPTOMS

You may notice slow network performance while copying files when you are using the TCP/IP protocol with a 100-MB network adapter. You may experience this degraded performance while using Windows Explorer in Windows NT 4.0 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-MB network cards, this problem is not specific to Windows NT.

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: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it.

• 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 (Regedt32.exe). 2. Go to the following subkey:

           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 enter the following information:
  
        Value Name: Adaptive_ifs
        Value Type: REG_DWORD
        Data: 1  (enable adaptive algorithm)
  
     The adaptive algorithm to detect collisions and tune the interframe gap
     is enabled by default. Setting it to 0 disables 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 choose 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 will wait to receive an ACK from the receiver before sending more data, thereby avoiding the potential for collision.

  The TcpWindowSize parameter normally does not exist in the registry, so it needs to be created using the following steps:

  WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

  For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it.

  1. Start Registry Editor (Regedt32.exe).

  2. Go to the following subkey:

           HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
           Services\Tcpip\Parameters
  
     3. Click Add, click Value, and enter the following information:
     
        Value Name: TcpWindowSize
        Value Type: REG_DWORD
        Data: 2920 (decimal) - Number of bytes
        Set it to Decimal 2920 for Ethernet (and two times the maximum TCP
        data size on other networks. This setting should not have to be
        modified for other networks, however, because Token Ring, FDDI, and
        so on, do not have collisions as Ethernet does).
  
     NOTE: Modifying this parameter could significantly affect performance.
     In general, on a WAN network or a regular 10-MB network, depending on
     the topology, there will be some latency between the sender and the
     receiver. Therefore, the potential for collisions due to TCP/IP ACKing
     behavior does not exist. Tuning TcpWindowSize in this case will only
     reduce throughput.
  
  

   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  SMB   C read & X, FID = 0x804, Read 0x10c5
19 SERVER CLIENT  SMB   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

Frame 18: TCP: len:   64, seq: 585297-585360, ack:734154,

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,

Frame 22: TCP: len:    0, seq:    585361-585361, ack: 738511,

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 Windows Explorer File Copy

When the same file copy is initiated using a command prompt, or using Windows Explorer in Windows NT 4.0, 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 SMB C read & X, FID = 0x1004, Read 0xf000 11 SERVER CLIENT SMB 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

11 SERVER CLIENT  TCP len: 1460, seq: 6992081-6993540, ack:    404791

12 SERVER CLIENT  TCP len: 1460, seq: 6993541-6995000, ack:    404791
13 SERVER CLIENT  TCP len: 1460, seq: 6995001-6996460, ack:    404791

>**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

16 CLIENT SERVER  TCP len:    0, seq: 404791-404791, ack:   6996461

17 CLIENT SERVER  TCP len:    0, seq: 404791-404791, ack:   6999381

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.

Additional reference word: prodnt

Keywords          : nthw NTSrvWkst nttcp kbnetwork
Version           : WinNT:3.51,4.0
Platform          : winnt