Microsoft KB Archive/177266

= Remote directory lists are slower than local directory listings =

Article ID: 177266

Article Last Modified on 2/22/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 4.0 Developer Edition
 * Microsoft Windows NT Server 4.0 Standard Edition
 * Microsoft Windows XP Professional

-



This article was previously published under Q177266



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
When you list the contents of a remote folder to which your computer is connected by TCP/IP, the results may take much more time to display than when you view a local folder.

Note This delay occurs whether you use Windows NT Explorer or a command prompt to view the folder. This issue is not specific to any particular network configuration.



CAUSE
Some additional delay when viewing a remote directory can be expected because of the additional overhead involved with sending requests over the network. How much delay can be attributed to this cause will depend on various factors such as overall network bandwidth, current network usage, cache size on the server, and so on.

One source of delay associated with processing a directory listing comes directly from the interaction between the buffer sizes used by the SMB protocol layer and the behavior of TCP/IP's delayed acknowledgements.

At the level where a Windows NT client is processing a "DIR" command, Windows NT will, by default, request no more than 16,384 bytes or up to 170 files for each SMB "transact2 findnextfile" transaction. The number of bytes for each file will vary, in general, based on the number of characters in the names of the files being enumerated.

The SMB transaction may be transmitted in multiple blocks that, in turn, may each require multiple IP frames to be transmitted over the network. If the number of frames for each "block" is odd, greater than 1, and there is no other network traffic between the systems involved, TCP/IP can fall into a situation where it must incur a 200 millisecond delay for every partial SMB response.

This problem is likely to be most pronounced in directories that contain very many files or that contain files with very long names. One way to determine whether you are likely experiencing this sort of delay is to perform two DIR commands against the same directory simultaneously from two separate command prompt windows. By adding a second source of network traffic, there will be more TCP/IP frames that can carry acknowledgements without having to wait for the delayed acknowledgement timer to expire. Therefore, if this is the source of the delay, the speed of both directory listings should be faster than one by itself. You may need to perform this test several times because the timing of the two DIR commands is important.



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 work around this issue, use the following steps to edit the SizReqBuf registry value on the server:  Start Registry Editor (Regedt32.exe). Locate and click the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

 On the Edit menu, click Add Value, and then add the following registry value:

Value name: SizReqBuf

Data type: REG_DWORD

Data: 512 - 65535 (bytes in decimal, or 200 - FFFF hexadecimal)

Default: 4356

Note Small buffers use less memory and large buffers can improve performance. The exact value that works best in an environment depends on the specific configuration of that environment, but 14596 is a value that has been shown to work well in a fairly standard Ethernet environment. By default, this setting is 4356 bytes on computers. On servers that have more than 512 MB of memory, this value is increased to 16 KB. A receive buffer that is larger can improve performance on query directory and similar commands, but at the price of more memory per work item. Quit Registry Editor, and then use the following commands to restart the Server service:

'''net stop server

net start server'''





MORE INFORMATION
According to RFC 1122, TCP uses delayed acknowledgments (acks) to reduce the number of packets sent on the media. The Microsoft TCP/IP stack takes a common approach to implementing delayed acks. As data is received by TCP on a given connection, it only sends an acknowledgment back if one of the following conditions is met:
 * If no ack was sent yet for the previous segment received.

-or-
 * If a segment was received, and no other segment arrives within 200 milliseconds for that connection.

In summary, normally an ack is sent for every other TCP segment received on a connection, unless the delayed ack timer (200 milliseconds) expires. There is no registry parameter to configure or disable delayed acks.

For additional information on TCP/IP, please see the following white paper available on the Microsoft anonymous ftp server:

File Name: Tcpipimp2.doc

Location : ftp.microsoft.com

Title : "Microsoft Windows NT 3.5/3.51/4.0: TCP/IP Implementation Details TCP/IP Protocol Stack and Services, Version 2.0"

Keywords: kbnetwork kbprb KB177266

-

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

© Microsoft Corporation. All rights reserved.