Microsoft KB Archive/169789
Article ID: 169789
Article Last Modified on 11/27/2007
- 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
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.
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.
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:
where <x> 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)
- 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:
- Start Registry Editor.
- Locate the following registry key:
- 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.
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"
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.
Additional query words: prodnt
Keywords: kbproductlink kbnetwork KB169789