M
Miles Erickson
(Caution: my e-mail address is masquerading as a palindrome.)
PROBLEM:
When attempting to view a remote directory containing a large number
of files, the directory listing takes a very long time. On my
client's network, a directory containing 5,691 files took 26 seconds.
In Windows Explorer and in File Open/Save dialog boxes, the user sees
an animated "flashlight" while waiting for the directory listing to
complete.
Some users reporting this problem note that Windows 95/98 machines on
the same network are not affected, even when accessing the same
directory on the same server.
CAUSE:
At the SMB protocol layer, directory listings are retrieved in blocks
of 16KB or no more than 170 files. When a remote directory contains
many files or contains files with long names, a complete listing may
be broken into many such blocks. Each block may be broken into
multiple IP frames. If the number of IP frames is greater than one
and odd (which might happen for every second block, on average), then
the client will wait 200 milliseconds before sending an
acknowledgement to the server, unless there is other network traffic
between the two machines.
Obviously, when there are thousands of files, these 200-millisecond
pauses can add up to a substantial delay. You can see these pauses
happening in real time by requesting a "dir" of a remote directory
from the command prompt.
MICROSOFT SUGGESTS:
This "delayed acknowledgement" is specified in RFC 1122 as a means of
reducing unnecessary network traffic. Unfortunately, it wreaks havoc
on directory listings, and Microsoft does not provide a way to disable
it.
However, Microsoft suggests a workaround: setting the registry value
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SizReqBuf"
to 14596 (REG_DWORD). I tried this suggested solution on my client's
network and found it to be useless in my case. Your mileage may vary.
MY SOLUTION:
Use NetBEUI instead of TCP/IP. On my client's network, this reduced
the directory listing delay from 26 seconds to less than one second.
Since Windows XP doesn't include NetBEUI in a standard installation,
you'll need to install two system files before installing it as a
protocol under your network connection properties. All you need to do
is copy "System32\Drivers\Nbf.sys" and "Inf\Netnbf.inf" from a Windows
2000 machine.
DO NOT use the version of NetBEUI included on the Windows XP CD-ROM.
Microsoft says that it's "unsupported" and there seems to be good
reason for this: it has trouble communicating with Windows 2000
machines using NetBEUI. I've had no problems whatsoever using the
Windows 2000 version of NetBEUI on XP machines.
Of course, after you install NetBEUI on all client and server
machines, you will need to remove the binding between "File and
Printer Sharing for Microsoft Networks" and "TCP/IP" in your server's
advanced settings. Do not actually *remove* the TCP/IP protocol.
Just *unbind* it. If you uninstall TCP/IP, you will not be able to
connect to the Internet.
ADDITIONAL RESOURCES
MSKB Article # 177266 provides a technical description of the problem
and a suggested solution involving a registry modification. (The
suggested workaround was *not* successful for my client's network,
your mileage may vary.)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;177266
MSKB Article # 301041 provides instructions for installing NetBEUI on
Windows XP machines. Do not use the version on the Windows XP CD-ROM
as Microsoft suggests; copy the required files from Windows 2000
machine instead.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;301041
DISCLAIMERS:
I am a mortal human being, and what works for me might not work for
you. I am providing this information free of charge. If you choose
to attempt anything that I've suggested here, you implicitly assert
and agree that: (1) you know what you're doing; (2) you are taking
responsibility for your own actions; and (3) that you agree to hold my
harmless for any damages that might result from said actions.
NetBEUI is not routable, so if you're trying to share access to your
file server over a WAN or the Internet, my suggested solution probably
won't work for you.
PROBLEM:
When attempting to view a remote directory containing a large number
of files, the directory listing takes a very long time. On my
client's network, a directory containing 5,691 files took 26 seconds.
In Windows Explorer and in File Open/Save dialog boxes, the user sees
an animated "flashlight" while waiting for the directory listing to
complete.
Some users reporting this problem note that Windows 95/98 machines on
the same network are not affected, even when accessing the same
directory on the same server.
CAUSE:
At the SMB protocol layer, directory listings are retrieved in blocks
of 16KB or no more than 170 files. When a remote directory contains
many files or contains files with long names, a complete listing may
be broken into many such blocks. Each block may be broken into
multiple IP frames. If the number of IP frames is greater than one
and odd (which might happen for every second block, on average), then
the client will wait 200 milliseconds before sending an
acknowledgement to the server, unless there is other network traffic
between the two machines.
Obviously, when there are thousands of files, these 200-millisecond
pauses can add up to a substantial delay. You can see these pauses
happening in real time by requesting a "dir" of a remote directory
from the command prompt.
MICROSOFT SUGGESTS:
This "delayed acknowledgement" is specified in RFC 1122 as a means of
reducing unnecessary network traffic. Unfortunately, it wreaks havoc
on directory listings, and Microsoft does not provide a way to disable
it.
However, Microsoft suggests a workaround: setting the registry value
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SizReqBuf"
to 14596 (REG_DWORD). I tried this suggested solution on my client's
network and found it to be useless in my case. Your mileage may vary.
MY SOLUTION:
Use NetBEUI instead of TCP/IP. On my client's network, this reduced
the directory listing delay from 26 seconds to less than one second.
Since Windows XP doesn't include NetBEUI in a standard installation,
you'll need to install two system files before installing it as a
protocol under your network connection properties. All you need to do
is copy "System32\Drivers\Nbf.sys" and "Inf\Netnbf.inf" from a Windows
2000 machine.
DO NOT use the version of NetBEUI included on the Windows XP CD-ROM.
Microsoft says that it's "unsupported" and there seems to be good
reason for this: it has trouble communicating with Windows 2000
machines using NetBEUI. I've had no problems whatsoever using the
Windows 2000 version of NetBEUI on XP machines.
Of course, after you install NetBEUI on all client and server
machines, you will need to remove the binding between "File and
Printer Sharing for Microsoft Networks" and "TCP/IP" in your server's
advanced settings. Do not actually *remove* the TCP/IP protocol.
Just *unbind* it. If you uninstall TCP/IP, you will not be able to
connect to the Internet.
ADDITIONAL RESOURCES
MSKB Article # 177266 provides a technical description of the problem
and a suggested solution involving a registry modification. (The
suggested workaround was *not* successful for my client's network,
your mileage may vary.)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;177266
MSKB Article # 301041 provides instructions for installing NetBEUI on
Windows XP machines. Do not use the version on the Windows XP CD-ROM
as Microsoft suggests; copy the required files from Windows 2000
machine instead.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;301041
DISCLAIMERS:
I am a mortal human being, and what works for me might not work for
you. I am providing this information free of charge. If you choose
to attempt anything that I've suggested here, you implicitly assert
and agree that: (1) you know what you're doing; (2) you are taking
responsibility for your own actions; and (3) that you agree to hold my
harmless for any damages that might result from said actions.
NetBEUI is not routable, so if you're trying to share access to your
file server over a WAN or the Internet, my suggested solution probably
won't work for you.