slug slow XP network response - a Solution!

B

Bruce Waldie

I have posted a reply to a message that was originally posted in November,
but since it is so hard to find anything in this group, I thought I would
repost it today on its own.

We had very similar experiences - slug slow network response under Windows
XP. I have found a solution that works for us, but first some history:

Prior to last summer we had a mix of Windows 95 and 98 clients accessing a
Win NT 4 Server. All was well with the world. Then we added our first XP
client and noticed that its access times were MUCH slower than 9x.
Example, one folder on the server with 3600+ files took less than 1 second
for the 9x clients to open, but XP was taking almost 15 seconds.

Thinking that our Pentium 100 (yes 100) with 96 meg of ram might be the
cause, I decided to upgrade the hardware to AMD 2600+ and 512 Meg ram. Of
course, NT 4 did not like the transplant so I had to reinstall it. Then I
discovered that we had an Upgrade disc and the 3.5 disc cannot be found.
Rats! Bite the bullet and purchase Server 2003. No difference - 9x could
still thumb its nose at XP.

I tried all sorts of combinations and permutations to test it all, and the
final conclusion is only one: XP TCP/IP is slug slow! Since the problem
happened under both NT4 and 2003, and ONLY to XP, the server and its
software was not the problem.


I tried adding the NWLINK/NETBIOS combination and it sometimes worked.
That is, it seemed that as long as netbios was the "default" things were
fine, but inevitably, after a couple of days, or a reboot, TCP/IP took over
and performance was down the drain again. I could fix it temporarily by
unclicking TCP/IP in the connection properties, try to access the server,
and then rechecking TCP/IP. This seemed to make NWLINK/NETBIOS the
"default" again for a while, but only for a while.

THE SOLUTION!

Add NETBEUI to all XP clients, and Server 2003, and make it the "default".

1) from the XP cd from \valueadd\msft\net\netbeui copy nbf.sys to
%systemroot%\system32\drivers and copy netnbf.inf to %systemroot\inf (you
will not find these files on the 2003 disc, use the files from the XP disc
instead).

2) open my network places/view network connections, and open properties on
your network connection. Use Install to add the NETBEUI protocol that now
appears. Click OK to close the properties dialog.

3) On the top menu, click on Advanced and Advanced Settings. NETBEUI
should be the top (first) protocol listed. If it isn't click on it and use
the up arrow (to the right) to move it to the top, in both locations.

DONE! Our performance is now sparkling and stable. Of course, NETBEUI is
no longer supported by Microsloth, so we will have to wait until they
acknowledge this TCP/IP speed problem and fix it. Until then, at least my
users can get a days' work in almost 1 day.


Please, all who try this, let me know how it worked for you.

Bruce Waldie, P.Ag.
PhotoComp Systems Inc.
 
K

Ken Wickes [MSFT]

There is no real reason why TCP/IP should be slower. The problem is likely
with DNS. Do the transfers happen at reasonable speed if you use the
numerical IP address?
 
B

Bruce Waldie

Thanks for the reply, Ken. Again, I HAVE to believe it is TCP/IP on XP
that is the problem, not DNS. The problem happened when we had NT 4
Server, and no DNS was involved then. I am pretty sure that we have Server
2003 set up as the DNS server correctly (it took three tries). The problem
ONLY happens with XP, not 2000, not 9x. I am also pretty sure I can set
the whole thing up without 2003 server at all, just xp machines in a
workgroup. I had tried, as one of my permutations, copying that 3600+ file
folder onto my Win98SE machine. Same slow response by XP machines.

Also, I am not talking about transfer speeds, per se. My tests involved
using Windows Explorer to open a folder on the server that had 3600+ files
in it. I used that as an empirical way of measuring responses, but yes,
file transfer times were also affected.

I am hesitant to "break" one of my clients to test if mapping a network
drive to our server by IP (it would be \\192.168.5.11\perry). And, by the
way, response times were the same whether I navigated to the mapped drive,
or through My Network Places. However, in the interests of getting this
solved, and helping others (there are very many with this same problem) I
will try it tonight, once my users are gone, and let you know.

It is so nice to finally have a response from Microsoft about this. Let's
solve this together.


Bruce W
 
K

Ken Wickes [MSFT]

Well obviously TCP/IP on XP does run fine in the majority of circumstances.
What I'm concerned about is that there might be a number of unanswered DNS
requests going out before the client falls back on something else (maybe
WINS). You could probably tell this with a program like Network Monitor or
Ethereal. There are other possibilities that a change in the provider order
might fix.

Still, if it ain't broke...

--

Ken Wickes [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


Bruce Waldie said:
Thanks for the reply, Ken. Again, I HAVE to believe it is TCP/IP on XP
that is the problem, not DNS. The problem happened when we had NT 4
Server, and no DNS was involved then. I am pretty sure that we have Server
2003 set up as the DNS server correctly (it took three tries). The problem
ONLY happens with XP, not 2000, not 9x. I am also pretty sure I can set
the whole thing up without 2003 server at all, just xp machines in a
workgroup. I had tried, as one of my permutations, copying that 3600+ file
folder onto my Win98SE machine. Same slow response by XP machines.

Also, I am not talking about transfer speeds, per se. My tests involved
using Windows Explorer to open a folder on the server that had 3600+ files
in it. I used that as an empirical way of measuring responses, but yes,
file transfer times were also affected.

I am hesitant to "break" one of my clients to test if mapping a network
drive to our server by IP (it would be \\192.168.5.11\perry). And, by the
way, response times were the same whether I navigated to the mapped drive,
or through My Network Places. However, in the interests of getting this
solved, and helping others (there are very many with this same problem) I
will try it tonight, once my users are gone, and let you know.

It is so nice to finally have a response from Microsoft about this. Let's
solve this together.


Bruce W



From: "Ken Wickes [MSFT]" <[email protected]>
References: <[email protected]>
Subject: Re: slug slow XP network response - a Solution!
Date: Tue, 13 Jan 2004 15:13:29 -0800
Lines: 78
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <#[email protected]>
Newsgroups: microsoft.public.windowsxp.network_web
NNTP-Posting-Host: 207.46.125.17
Path:
edtnps82!newsfeed2.telusplanet.net!newsfeed.telusplanet.net!newsfeed.te
lus.net!news3.optonline.net!feed4.newsreader.com!newsreader.com!msrn-ou
t!msrtrans!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl Xref:
news.telusplanet.net microsoft.public.windowsxp.network_web:164591

There is no real reason why TCP/IP should be slower. The problem is
likely with DNS. Do the transfers happen at reasonable speed if you
use the numerical IP address?
 
M

My Name

Hey, I am willing to try anything to find the real solution to this, since
NETBEUI is not a long term solution. It is no longer supported by
Microsoft.

I will find these tools you mentioned, and try them, and let you know.

Still, why is it ONLY XP that has this problem. Can it not co-exist in a
non DNS environment like NT 4 Server?

By the way, I have received almost 100 email messages from people that have
tried my solution and found that it worked for them too. That indicates
that there are a lot of people who have experienced the same problem.

Still, I will try the tools you have suggested and will let you know what I
find.

Bruce W
 
T

thurb

I agree...I had the same problem and Bruce suggested that
I try adding Netbeui back in as the default protocol for
my LAN. It worked.....and it didn't affect the tcp/ip
setup for my WAN.....almost too easy a fix but thankfully
a fix none the less.

Ron
 
K

Ken Wickes [MSFT]

I think the provider order is different on XP, you might try moving
Microsoft Windows Network to the top of the list.

Network Connections folder, Advanced Menu, Advanced Settings, Provider Order
 
B

Bruce Waldie

You may have something here, Ken. While getting ready to test Ethereal, I
removed NETBEUI from one of our XP clients. It still shows sparkling
network performance! And that is with only TCP/IP and Network Monitor. I
had changed the Provider order on that one to be Windows Network first. I
will do some more testing on other machines, and see what happens.

Bruce W
PhotoComp Systems Inc.

p.s. sorry about some of my postings coming from a bogus address, etc. I
forgot to overwrite the "alias" I usually use to avoid spam. Those
messages were still from me.
 
K

Ken Wickes [MSFT]

I hope that solves it for you. If it does it probably means there is a
misconfigured WebDAV machine on your network, that's why everyone is not
affected. It's been explained here before but I don't remember exactly.

Still changing the provider order should be fine.
 
B

Bruce Waldie

I did some tests tonight on two of our XP clients. I unchecked (but did
not remove) NETBEUI on both, and moved the Windows Network provider order
to the bottom (not the top) just to see if that had an effect. It did not,
both clients still show good responses, even after rebooting them. (I did
not reboot the server 2003 though).

since we (and 100's of others) have been living with this problem for a
long time, I think it still shows that something is wrong. Why would the
problem be there for so long, go away when I installed NETBEUI, then still
stay away when I disable NETBEUI? Makes no sense.

OK, I readily acknowledge that I know very little, but what is a WebDAV
machine?

Bruce W
 
B

Bruce Waldie

OK, so I Googled WebDAV - Web Base Distributed Authoring and Versioning.
We have no such creature on our network. Why would you have EVER thought
of such an excuse?

Bruce W
 
K

Ken Wickes [MSFT]

Because I had the provider order backwards in my head, and "Web Client
Network" refers to WebDAV. Now that I check I see Terminal Server Network
is first in the default order.
 
K

Ken Wickes [MSFT]

If the problem really was caused by the client hitting a non-existant
provider then it could have gone away when the affected machine left the
network.
 
K

Kent W. England [MVP]

Ken said:
Because I had the provider order backwards in my head, and "Web Client
Network" refers to WebDAV. Now that I check I see Terminal Server Network
is first in the default order.
You might want to think about SMB message signing as a cause.
 
P

Peter Parker

Question, does this effect all XP machines? I have post a problem we had
after upgrading to XP Pro from various Windows versions. I had a few
machines that would be very slow network (internet) speed. The thing was
that they work fine in my test area. Now our single server is NT 4.0. Like I
said this only happened a few machines. The first one I replaced the network
cable from the wall to the computer. It looked like it was hit a few times.
This seemed to fix the problem. Now this cable worked fine with the machine
that was replaced. I had this happen a few other machines. Now on one other
machine I replaced the computer cable and the cable from patch panel to
network switch ( I was replacing them all anyway for clean up). This didn't
help. The Outlook backup file wants hours to backup (150MB). I finally
switch network ports and hours went to a minute. For some reason XP is touch
about the hardware it's connected to.
 
J

Juerg Thoeny

Hi

The problem can be solved by setting the DWORD TcpAckFrequency to 1 in
the registry: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Interface\[GID
of your Network Interface}\
You have to change this on your server and it works only after reboot.

There is also a Microsoft article which describes this:
http://support.microsoft.com/default.aspx?kbid=328890


Kind regards

Juerg
 
P

Parish

Juerg said:
Hi

The problem can be solved by setting the DWORD TcpAckFrequency to 1 in
the registry: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Interface\[GID
of your Network Interface}\
You have to change this on your server and it works only after reboot.

There is also a Microsoft article which describes this:
http://support.microsoft.com/default.aspx?kbid=328890

Thank you Juerg! That solved the same problem for me :)

I had seen the KB article your referred to, but it seemed to not be
relevant in my case because I have 3 PCs all running XP Pro-SP1, two of
which have identical network cards. None of the PCs had TcpAckFrequency
in the registry (which would be the same as having it set to 2 I guess?)
but only one machine has the problem. Have you any idea why this should
be so?

Just going off at a slight tangent, could you perhaps solve this one for
me? I have 7 GIDs under
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Interface\ most of which
are redundant. Two are my old 10Mbps NIC and one is my current NIC but
from when it was in a different PCI slot (I moved it in case the speed
problem was due to an IRQ sharing problem, possibly with the SCSI card
(the machine has SCSI disks)).

In Device Manager, selecting View->Show Hidden Devices, I try to
uninstall them but Windows gives the message "Failed to uninstall the
device. The device may be required to boot up the computer." This
happens even in Safe Mode (_without_ Networking). Have you any idea how
to get rid of these devices?

Thanks again for your input.

Kind regards,

Parish
 
B

Bruce Waldie

In answer to your question - no, we have one XP machine on the network that
does not show this behavior - it is quick to open our benchmark folder of
3600+ files, even with just TCP/IP installed. Another difference between
this machine and all the other XP boxes is that when you open "my network
places" it has already netcrawled and found all shares and shows them to
you. None of the XP boxes with the problem do that.

I have tested and certified all network cables and connections with a
Wavetek Lantek pro XL tester. I have also tested between just two
computers in the same room, with a different switch (even a different
manufacturer. It made no difference.

I would like to examine what is happening on that one computer that does
the netcrawl. Why do the others not do it?

Bruce
 
B

Bruce Waldie

Thanks for the input, but I cannot find any such key. Your example seems
to be incorrect, in that the key should be:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\PARAMETERS\InterfaceS\[GID

(that is, it is missing the PARAMETERS subkey and misses the S on
Interfaces)

And even the knowledgebase article 328890 has it wrong. It gives it as:

HKLM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\[GID

(That is, it is missing the SYSTEM subkey) Hardly promotes confidence in
the solution.

No matter, I cannot find such a TcpAckFrequency key anywhere in the
registry on my Server 2003 machine. The kb article indicates that such a
key should exist, and that its default is even 2. What is going on here?

Bruce Waldie




(e-mail address removed) (Juerg Thoeny) wrote in
 
P

Parish

Bruce said:
Thanks for the input, but I cannot find any such key. Your example seems
to be incorrect, in that the key should be:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\PARAMETERS\InterfaceS\[GID

(that is, it is missing the PARAMETERS subkey and misses the S on
Interfaces)

That's just a typo by Juerg.
And even the knowledgebase article 328890 has it wrong. It gives it as:

HKLM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\[GID

(That is, it is missing the SYSTEM subkey) Hardly promotes confidence in
the solution.

You are correct, the KB article misses \SYSTEM\ but that's just another
typo.
No matter, I cannot find such a TcpAckFrequency key anywhere in the
registry on my Server 2003 machine. The kb article indicates that such a
key should exist, and that its default is even 2. What is going on here?

No, read the SUMMARY section, it states (my emphasis):

TcpAckFrequency is a _NEW_ registry entry...

you have to add it; if it doesn't exist XP behaves as if it is set to 2.

HTH

Regards,

Parish
Bruce Waldie




(e-mail address removed) (Juerg Thoeny) wrote in
Hi

The problem can be solved by setting the DWORD TcpAckFrequency to 1 in
the registry: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Interface\[GID
of your Network Interface}\
You have to change this on your server and it works only after reboot.

There is also a Microsoft article which describes this:
http://support.microsoft.com/default.aspx?kbid=328890


Kind regards

Juerg
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top