Remote Directory Lists Are Slower Than Local Directory Listings

• Microsoft Windows NT Workstation version 4.0
• Microsoft Windows NT Server version 4.0

IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.

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.

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: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it.

To work around this issue, edit the SizReqBuf registery value using the following steps:

1. Start Registry Editor (Regedt32.exe or Regedit.exe).

2. Go to the following registry subkey:

         HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
         \LanmanServer\Parameters
   

   NOTE: The above registry key is one path; it has been wrapped for readability.

3. Create the SizReqBuf value using the following information:

         Value Name: SizReqBuf
         Data Type : REG_DWORD
         Data      : 512 - 65536 (bytes in decimal)
         Default   : 4096
   
      NOTE: The exact value that works best in a given environment will depend
      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.
   
   

4. Close Registry Editor and restart your computer.

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.

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://ftp.microsoft.com/bussys/winnt/winnt-docs/papers/
   Title    : "Microsoft Windows NT 3.5/3.51/4.0: TCP/IP Implementation
               Details TCP/IP Protocol Stack and Services, Version 2.0"

Keywords          : NTPROTOCOL NTSrvWkst nttcp kbnetwork
Version           : WinNT:4.0
Platform          : winnt
Issue type        : kbinfo