Remote directory lists are slower than local directory listings (177266)

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

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: