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.
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:
- Start Registry Editor (Regedt32.exe).
- Locate and click the following key in the registry, where Adapter GUID is the globally unique identifier (GUID) for the network adapter that connects to the clients:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Adapter GUID
- On the Edit menu, click Add Value, and then add the following registry value:Value name: TcpDelAckTicks
Data type: REG_DWORD
Value data: You can set this value to a range from 0 to 6. The default setting is 2 (200 milliseconds).
- Quit Registry Editor.
- Restart Windows for this change to take effect.
Note Adapter-specific values are listed under subkeys for each adapter. Make sure that you add the TcpDelAckTicks value to the following registry key:
Note If you are using Network Monitor, you can see the delays better if you use the following filter:
- Condition 1: No ACK is sent for the previous segment that is received.
- Condition 2: A segment is received, but no other segment arrives within 200 milliseconds (the default value) for that connection.
Typically, an ACK is sent for every other TCP segment that is received on a connection unless the delayed ACK timer (200 milliseconds) expires. You can adjust the delayed ACK timer by using the procedure that is described in the "Resolution" section of this article to add the TcpDelAckTicks registry value (this value is new in Windows 2000).
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:
For more information about this problem, click the following article number to view the article in the Microsoft Knowledge Base: