[dubsdj]

Does anybody know if there is a work around for an issue where it seems to take ages to connect to a share that is on an XP computer?

Anybody else seen this?

[Tripredacus]

Yes. Try unchecking the boxes for Link-Layer Topology Discovery Mapper I/O Driver and Link-Layer Topology Discovery Responder under the properties of your network adapter and see if you see an increase in speed.

[dubsdj]

Thanks for your post

I don't seem to have anything like that on my Marvell Yukon gigabit network card

[Tripredacus]

On our Vista machines, that is how we are able to disable the Receive Window Auto-Tuning feature.

[dubsdj]

ooh ic its the auto tuning thing... ah i know how to disable that from the command prompt.

thanks

[fizban2]

dubsdj, on Jun 13 2008, 08:58 AM, said:

ooh ic its the auto tuning thing... ah i know how to disable that from the command prompt.

thanks

both the mapper and the linker should be listed in the properties for the network card (network and sharing center -> manage network connections -> right click on your NIC and go to properties. the items should be listed there is TCP/IP and the other items available to the NIC

[dubsdj]

both the mapper and the linker should be listed in the properties for the network card (network and sharing center -> manage network connections -> right click on your NIC and go to properties. the items should be listed there is TCP/IP and the other items available to the NI


Well it wasn't any of those eg.. mapper and linker but you were right that it was in the network card properties. The driver that was causing the issue was this:

Symantec Network Security Intermediate Filter driver

I disabled that and now the shares are opening at lightning speed..

[dubsdj]

Maybe that Mapper and linker thing works in most cases, I have read this on a lot of google searches so I think what you say is probably the solution

[fizban2]

dubsdj, on Jun 13 2008, 04:53 PM, said:

Maybe that Mapper and linker thing works in most cases, I have read this on a lot of google searches so I think what you say is probably the solution

truthfully the mapper and linker will only apply in IP V6 situation but some people find that their router or network tries to respond on IPv6 and it can cause slowness because vista will try and use V6 first... glad to hear you solved the issue!

[Tripredacus]

I'm reopening this discussion because of my own experiences. I am getting mixed results with this result. For versions that allow it, I disable these mapper and i/o drivers with group policy. In other versions I disable it using the registry. Say for example, in Home Premium (which has no GP support) the discovery mapper is the only service that is enabled, and the i/o driver is disabled, while both services are set for manual AND enabled on the NIC itself. However, our current LAN is set up in two segments or IP ranges. All vista machines on one range work properly once my settings are applied. But all machines on the other range do not! They operate as if the i/o and mapper are enabled, even if I were to manually unselect them.

I can also confirm that the policy is active and have forced a gpupdate. Now these machines are communicating with a 2003 Std server, and say the next station to the vista on this "slow" range has XP. the XP has no problem accessing network resources.

As an example, a Vista business PC has taken over an hour to install Realtek Sound drivers off the network, and the XP machine next to it took 3 minutes. And a Business PC on the other range takes 3 minutes.

Since it would appear that perhaps there is a cfg problem with one of our segments, what could possibly cause Vista PCs to be slow on it and XP to be not?

I can also verify that if I take the "slow" Vista PC off the "slow" segment and connect it to the other one, network shares open very fast and network speed is normal.

[cluberti]

Gotta start at the bottom on this. You probably want a network trace on a slow and a fast machine on the same segment so you can see if it's a delay in the client making a request for data, or slowness in it receiving data.

[Tripredacus]

All ip traffic appears to be normal. traces are basically pointless because there is only 1 hop to be had. These segments do not have access to the internet. I ran a 1k ping to the file server and average time was 1ms, mean time was 2.5ms (actual range 1-4). While running this ping (using ping ip -t -l 1000) I had an XP machine ping the file server, which got <1ms, as well as ping the Vista which was also <1ms.

I am not sure what else I can run on it... I mentioned this behaviour to our network admin and he's drawing up a blank on it as well. I have tried connecting using the \\IP instead of \\UNC and the same thing. I try pinging while waiting for the share to open, and all 1ms. Now I get the same stastictics on the other segment but the actual visual response time is faster. The transfer speeds (as reflected by the info box) always shows a <1MBps speed on the slow segment, and a ~10MBps+ on the fast segment. ping times during these obvious slow times are normal.

Also, when I traverse folders, as an example. I open a folder on the share. It waits about 20 seconds, then opens the folder but all the icons are generic. There is a little green progress bar that moves slowly through the address bar. It takes maybe 60 seconds for it to make the entire address bar green. It then changes the icons to whatever they are supposed to be. Also during this time, on the explorer bar (folders) it will show the folder, but still collapsed, and have a magnifying glass on it that moves slowly. When it finally loads, it expands the folder as well.

I am not sure if I have seen this properly, but on the slow segment, it always shows the "offline status" in the info bar on the bottom. I have not noticed this showing that info on the fast segment. All vista is doing this, but we use a single image, which is modified with Group Policy.

[Mr Snrub]

Quote

I can also verify that if I take the "slow" Vista PC off the "slow" segment and connect it to the other one, network shares open very fast and network speed is normal.

You mean the difference in the fast & slow network segments are not logical, but physical?
What are the switches involved in the good & bad scenarios, using the same client & server to test?

ICMP round-trip time might test fine, maybe even UDP, but SMB communication is over TCP so a pure ping test to measure latency is not so useful.
How does RDP work to the server from the client, compared between the 2 segments?

Have you tried forcing the duplex & speed of the NIC on the client to different settings and compare the results in the bad segment?

Network traces are still useful even where routers are not involved - it would be interesting to take a look at a simultaneous network trace from a Vista client and the W2K3 server being accessed, then compare with simultaneous traces from the same server and an XP client doing exactly the same test.

A typical test routine would be:

Quote

On the client:
- open a command prompt window, keep it open for the duration of the test
- at the command prompt, enter: IPCONFIG /FLUSHDNS & ARP -d *

[start network tracing on both the server and client now]

On the client:
- at the command prompt, enter: PING -l 111 servername
- hit Win+R, enter \\servername to enumerate the shares on that server
- as soon as the results appear, at the command prompt, enter: PING -l 222 servername
- double-click a share in the Explorer window
- as soon as the results appear, at the command prompt, enter: PING -l 333 servername
- drag & drop a "reasonable sized" file from the share (something like 1MB)
- as soon as file copy completes, at the command prompt, enter: PING -l 444 servername

[stop network tracing on both the server and client now, save the captures]

If you want to do that test on the Vista client and then the XP client and share the capture files I'd be happy to take a look to see if we can figure out what is going on.
(The pings are for marking the trace so it is obvious when the results came in, and the sizes are to distinguish from any other ICMP traffic the client may generate.)

[Tripredacus]

OK I will once we get another PC in... I shipped the last one.