Article ID: 321098 - View products that this article applies to.
This article was previously published under Q321098
If you copy files from a Microsoft Windows 2000-based client computer, a Microsoft Windows XP-based client computer, or Microsoft Windows Server 2003-based client computer to a network share on a domain controller that is running Windows 2000 or Windows Server 2003, network performance is slower than if you copy the same files to a member server that is running Windows 2000 or Windows Server 2003. You may notice this problem if you copy many small files; however, you may not notice this problem if you copy a few large files. This problem only occurs if you either use Microsoft Windows Explorer to copy the files or if a Windows Explorer window is open and connected to the target server. However, if you use Xcopy.exe to copy the files and all of the Windows Explorer windows are closed, you do not experience this problem.
This problem occurs because server message block (SMB) write operations to a domain controller that is running Windows 2000 or Windows Server 2003 may experience a delay of up to 200 milliseconds between file copies.
If you review a trace of the problem, you notice that the delay occurs after the client sends the server an SMB Notify Change command with the FID entry that matches the FID entry of the target folder. Windows Explorer posts a Notify Change request on the network share, which asks to be notified if something changes in the folder that appears in the right pane of Windows Explorer. If a domain controller receives the Notify Change request, it does not respond to it immediately; it does not send packets for up to 200 milliseconds. At that point, a simple Transmission Control Protocol (TCP) acknowledgement (ACK) packet is sent and the file operation resumes as usual.
This behavior is a result of the interaction between two core networking components of Windows 2000, TCP delayed ACKs, and thread prioritization on domain controllers. Thread prioritization allows a domain controller to properly prioritize directory services and account management operations before some SMB activities, such as responding to Notify Change requests.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/322756/ )How to back up and restore the registry in Windows
When you consider this problem, be aware that it only occurs in very specific circumstances; this problem only occurs if a client is using Windows Explorer to copy a large number of files to a Windows 2000-based domain controller. If you change the value of the delayed ACK timer, you can prevent some of the symptoms from occurring; however, if you modify a core TCP/IP value, you may experience unexpected results in the future. Therefore, Microsoft recommends that you consider other alternatives before you modify the timer. Other solutions include moving the file shares to a member server or using another tool (such as Xcopy or Robocopy, which is part of the Windows 2000 Resource Kit) to copy large numbers of files to a domain controller.
On the domain controller, you can edit the TcpDelAckTicks registry value to adjust the TCP delayed ACK timer. If you change the TCP delayed ACK timer to a lower value, the server sends an ACK packet more frequently but at shorter intervals.
Note that on a high latency, highly saturated segment, the net increase in the ACK packets from the domain controller may put additional strain on the network. To make sure that the changed TCP delayed ACK timer value does not cause additional bottlenecks, test the value thoroughly.
If the network can handle the extra ACK packets, apply the following pre-Service Pack 3 (SP3) hotfix to Windows 2000 Service Pack 2 (SP2) so that you can modify the delayed ACK timer value:
311833After you apply this hotfix, use the following procedure to add the following registry value that specifies the custom parameter for the delayed ACK timer:
(https://support.microsoft.com/kb/311833/ )The TcpDelAckTicks registry value has no effects on ACK timeouts
Note Adapter-specific values are listed under subkeys for each adapter. Make sure that you add the TcpDelAckTicks value to the following registry key:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Adapter GUIDDo not add this value to the following registry key:
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
In network traces you can see that the client sends the "SMB: C NT transact - Notify Change" packet. The Windows 2000-based domain controller sends back an ACK packet to the client 200 milliseconds later. After the client receives the ACK packet, the client begins the next SMB operation and copies the next file.
Note If you are using Network Monitor, you can see the delays better if you use the following filter:
SMB:Command == 0xA0 ( NT transact )Use this filter in combination with the following display options:
Time: (x) Seconds from previous frameYou can identify the corresponding requests and answers by looking at the following SMB frame attribute:
SMB: Multiplex ID (MID)The Delayed Acknowledgments functionality is based on Request for Comments (RFC) 1122. TCP uses delayed ACKs to reduce the number of packets that are sent on the network. The Microsoft TCP/IP stack takes a common approach to implementing delayed ACKs. When the data is received by TCP on a connection, the stack only returns an ACK if one of the following conditions is met:
Note Be aware that if you change the TcpDelAckTicks registry value, you may experience unexpected effects in the future. Therefore, Microsoft recommends that you consider other alternatives before you modify the timer.
The delay occurs if the previous packet was acknowledged and the Notify Change request response is queued by a domain controller for a period of time that sometimes exceeds 200 milliseconds. Because the default ACK timer counts to 200 milliseconds, the TCP ACK packet occurs 200 milliseconds after the Notify Change request is received from the client. Because the client waits for a response from the server before it proceeds with the next SMB operation, the delay occurs while the server's delayed ACK timer counts to its threshold. If you perform a network trace, you notice that not every Notify Change request from the client experiences a delay.
The Notify Change request that does not experience the delay is immediately preceded by another packet which is not acknowledged. Therefore, the acknowledgement is not delayed in the domain controller's acknowledgement because the first of the conditions that is described at the beginning of this section is met. The Notify Change requests that do experience the delay have had the previous packets acknowledged; therefore, the domain controller does not respond back until the delayed ACK timer expires (the default value is 200 milliseconds) because the second of the conditions that is described in this section is triggered.
You cannot modify the thread prioritization of a domain controller; therefore, you must change the TCP delayed ACK timer value to a lower value to prevent the symptoms that are described in the "Symptoms" section of this article from occurring. After you do so, the server sends ACK values more frequently but at shorter intervals.
For more information about the TcpDelAckTicks registry value, refer to the white paper that is located on the following Microsoft Web site:
Microsoft Windows 2000 TCP/IP Implementation DetailsFor more information about this problem, click the following article number to view the article in the Microsoft Knowledge Base:
270926On a client that is running Windows XP or Windows Server 2003, there is a new registry key named TcpAckFrequency that controls TCP ACKs before the delayed ACK timer is reached. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/270926/ )How to troubleshoot network file copy issues in Windows 2000
328890For more information, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/328890/ )New registry entry for controlling the TCP Acknowledgment (ACK) behavior in Windows XP and in Windows Server 2003
(https://support.microsoft.com/kb/321169/ )Slow SMB performance when you copy files from Windows XP to a Windows 2000 domain controller
Article ID: 321098 - Last Review: March 1, 2007 - Revision: 4.5