Peer2Peer slow enumeration of directory contents

  • Thread starter Thread starter Trent Jones
  • Start date Start date
T

Trent Jones

Ladies & Gentleman,

I very rarely post a question, but this one is killing me. I cannot
figure this one out. Here is the breakdown:

A small network with two computers both running Windows XP Professional SP2

Peer2Peer Network access with the file share residing one computer #1
Computer #1 is running McAfee Security Center
Computer #2 is running Norton Personal Firewall

I have disabled both firewalls and gotten the same results

I have booted both systems in Safe Mode with Networking Support and
gotten the same results

I have brought a Laptop running Windows XP SP2 in and connected to the
file sharing computer with a cross over cable and got the same results

This directory has over 5000 small files in it and it takes forever to
refresh the directory listing and to save files to the network share

I also copied the directory to Computer #2, shared it and tried
connecting via Computer #1, I also got the same slow repsonse

I am running out of ideas and am beginning to lean toward a flaw with
Windows XP and its enumeration with directories that have a lot of small
files in them

Can someone give me a little insight into this issue?

Thanks,

Trent
 
Ladies & Gentleman,

I very rarely post a question, but this one is killing me. I cannot
figure this one out. Here is the breakdown:

A small network with two computers both running Windows XP Professional SP2

Peer2Peer Network access with the file share residing one computer #1
Computer #1 is running McAfee Security Center
Computer #2 is running Norton Personal Firewall

I have disabled both firewalls and gotten the same results

When did all this start?...prior to sp1?...after sp1?...after sp2?
That should be your first investigation.
I have booted both systems in Safe Mode with Networking Support and
gotten the same results

Uninstall Norton...ALL of it...not just the firewall. Then test.

Then uninstall McAfee...ALL of it...not just the firewall. Then test.

You can always simply reinstall them again after you find the problem.

Right now, I'd guess one or both is checking executables as you move
them. Have you done a defrag lately?...got plenty of room on each
drive?
I have brought a Laptop running Windows XP SP2 in and connected to the
file sharing computer with a cross over cable and got the same results

Are you running a router?
This directory has over 5000 small files in it and it takes forever to
refresh the directory listing and to save files to the network share

I also copied the directory to Computer #2, shared it and tried
connecting via Computer #1, I also got the same slow repsonse

I am running out of ideas and am beginning to lean toward a flaw with
Windows XP and its enumeration with directories that have a lot of small
files in them

What size clusters are you usin' on each machine?

Good luck...let us know.


Have a nice one...

Trent

Budweiser: Helping ugly people have sex since 1876!
 
Trent,

This all started when my customer bought a brand new HP desktop with XP
SP2. I have removed both anti-virus programs & firewalls. There was no
change in the response time. Done a defrag already and both drives have
plenty of room. I'm not sure what the cluster size is? Where can I find
that information? There is a wireless router with a 4-port switch from
Linksys in between the two PCs but I have already bypassed that with the
laptop and connected via crossover cable.

Any help would be very much appreciated.

Thanks,

Trent
 
You can find the cluster size with disk defragmenter (View report after
analyze or after defrag). Default is 4 KB.
 
I found my answer much by sheer luck or accident. The answer to this
problem which you will only find on very small networks or peer to peer
networks is here:

Remote Directory Lists Are Slower Than Local Directory Listings

http://support.microsoft.com/default.aspx?scid=kb;en-us;177266&sd=ee

This, in my opinion is a design flaw on Microsoft's part since as stated
in the article:

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.

This problem cost me a lot of time. I am not thankful for this design
attribute and will share it wuth as many as I can to avoid them wasting
time.

Thanks for all your comments and suggestions.

Trent
 
I found my answer much by sheer luck or accident. The answer to this
problem which you will only find on very small networks or peer to peer
networks is here:

Remote Directory Lists Are Slower Than Local Directory Listings

http://support.microsoft.com/default.aspx?scid=kb;en-us;177266&sd=ee

This, in my opinion is a design flaw on Microsoft's part since as stated
in the article:

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.

This problem cost me a lot of time. I am not thankful for this design
attribute and will share it wuth as many as I can to avoid them wasting
time.

Thanks for all your comments and suggestions.

Trent
 
I have experienced the same problem. I am about to read the MS article at
the link Trent posted, but want to share a workaround that works for me --
cheap, stupid NICs.

I run PtoP TCP/IP static addresses in a 35 machine XP and Win 98 setting. I
use the Win 98 machines as 'servers' because they transfer data much faster.
I have a "Dump" where I put copies of all documents, about 30,000 docs.

Embedded Intel NICs are worthless in this enviornment, taking 2-3 minutes to
access the file directory in WordPerfect 6.1, even slower in Explorer. Cheap
Netgear, Linksys, and now Hawking 1000's open up in 6-8 seconds. The Intels
are apparently too smart for their own good.

Thanks for posting that link, hope this post helps others.

Tom Keane
 
Back
Top