Microsoft KB Archive/169789

= High Rate of Collisions on 100-Megabit Networks =

Article ID: 169789

Article Last Modified on 11/27/2007

-

APPLIES TO


 * Microsoft Windows 2000 Server
 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Professional Edition
 * Microsoft Windows 2000 Datacenter Server
 * Microsoft Windows NT Workstation 3.51
 * Microsoft Windows NT Workstation 4.0 Developer Edition
 * Microsoft Windows NT Server 3.51
 * Microsoft Windows NT Server 4.0 Standard Edition

-



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:

 Start Registry Editor.  Locate the following registry key:         HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\e100b\Parameters where  is the number of your interface card.  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.</li></ol> </li> 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: <ol> Start Registry Editor.</li> Locate the following registry key:

</li> 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.</li></ol> </li></ul>

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"

<div class="moreinformation_section">

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:

<pre class="fixed_text">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:

<pre class="fixed_text">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:

<pre class="fixed_text">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:

<pre class="fixed_text">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.

Additional query words: prodnt

Keywords: kbproductlink kbnetwork KB169789

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.