High Rate of Collisions on 100-MB Networks

ID: Q169789

The information in this article applies to:

Microsoft Windows NT Workstation versions 3.51, 4.0
Microsoft Windows NT Server versions 3.51, 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:

Start Registry Editor (Regedt32.exe).

Go to the following subkey:


         HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ 
         Services\e100b"x"\Parameters

where "x" is the number of your interface card.

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.

Start Registry Editor (Regedt32.exe).

Go to the following subkey:


         HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ 
         Services\Tcpip\Parameters

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.

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

At the TCP level:


Frame 18: TCP: len:   64, seq: 585297-585360, ack:734154,
>Client sends 64 bytes of data (SMB 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 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
>Client sends 64 bytes of data (SMB command to read 4KB);

11 SERVER CLIENT  TCP len: 1460, seq: 6992081-6993540, ack:    404791
>Server sends the piggy back ACK, and the SMB 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.

Additional query words: prodnt


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

Last Reviewed: February 19, 1999