LAN speed issues :-/

My LAN setup:
XP Home Home Desktop 'server' connected to ADSL router.
Mini-hub connected to router.
XP- Home Desktop 'workstation' connected to mini-hub.
XP-Media Laptop using wifi to router.
Music player connected to mini-hub.

Mostly it works well but there is one irritating issue that plagues me.

I don't download stuff from the internet very often but when I do I usually want to save it to a scratch volume on the server. What often happens though is that there is either a godawful delay before the Save As.. dialog appears or a godawful delay before the download progress dialog appears.

I've read on the web about various causes of this and I tried removing shortcuts from the desktop but it didn't help. It's annoying :-/

I take it that the server is remote from the PC being used in the instances where delay happens. The delay is probably caused by the server checking its directory/file structure and reporting same over a comparitively slow interface. The solution is to store the 'scratch' file locally.

The server is not remote - at least not by my standards. It's upstairs in my study and connected either by a 54Mb wifi link or 100Mb ethernet.

Perhaps you didn't understand my message so I'll try explain it again.

I'm talking about downloading a file /from the internet/ and choosing to write it to /another machine on my LAN/ rather than writing it /to the harddrive of the machine running the browser/.

As far as I'm aware there is no reason why I shouldn't be able to download to another machine on my network. Okay so it'll be a bit slower than doing it to a local drive but given that it's coming from the net at no more than 10Mb (I have ADSL2+) it should be fine.

Hmmm. In discussing this at home I've been reminded that sometimes just accessing a file from the internal server for certain purposes can be slow. It's okay to just copy it (in which case it usually transfers at about 60Mb to 70Mb over the ethernet) but running an executable can sometimes lead to the same godawful (half a minute or more) delay.

Edited by Andrue (Wed 11-Jul-07 13:13:29)

I did understand your question and I did answer it. Remote in computing terms means not local.

In reply to:

---

The server is not remote - at least not by my standards.

---

As john2007 has already said, if it's not the machine you're sitting at then it's not local - ergo it's remote.

In reply to:

---

It's upstairs in my study and connected either by a 54Mb wifi link or 100Mb ethernet.

---

Well it's either one or the other - which? It can't really be using both at the same time (well technically it could but I doubt that's what you're doing).

Bear in mind how the download process works. When downloading via a PC to a network share, the download process may elect to create a temporary file on your local PC and then move this to the intended destination once the download has completed. This avoids the issue of the download failing completely if the network share becomes unavailable or if it is on the far end of a slower link (e.g. a WAN).

The other thing that might be an issue is if the "server" has a mismatch between your switch/router and it's NIC for the duplex or speed settings. Whilst 9 times out of 10 the autonegotiation works properly, sometimes it doesn't.

Looking at your topology, your server is connected to your router and your PC is connected to a "mini-hub". This means that the connection between the "mini-hub" and the router is expected to carry traffic from the Internet to your PC then carry it back to your server - very much a bottleneck. Coupled to this is the fact that the "mini-hub" - if it is indeed a hub and not a switch - is a shared-media device, which means that traffic coming from the router effectively goes to ALL ports (only the specific end-station actually does anything with it).

BTW john2007 did offer some sound advice and there was no need to suggest that he hadn't understood the problem.

I'm not trying to insult anyone but it still doesn't sound like either of you have understood my problem. This isn't (I don't think) a raw throughput issue. I suppose Windows Explorer /might/ be issuing an SMB command that results in huge amounts of data being sent from my server to my client but I think it unlikely even for that pile of poo

What doesn't seem to be being explained is how two machines can transfer data back and forth at a goodly speed (typically around 60Mb/s) yet some operations (mostly those relating to Explorer it seems) can hang just querying metadata.

Once the 'Save As..' dialog has finally sorted itself out and I click [Ok] the transfer occurs as fast as my internet connection can handle. I typically see transfer rates of 800kB/s.

As an example downloading a 10MB file from the internet might take nearly a minute. 50 seconds while either or both of my machines faff around (during which time my router's WAN light is pretty much idle) then 10 seconds actually getting the data down from the internet (during which my router's WAN light is on solidly) onto my server's hard disk.

The problem here (as I see it) is not the raw throughput between my two machines. The problem is that sometimes either my client or my server choke while Windows Explorer is performing some query. There are a number of issues that can cause this and I've investigated most. I just hoped someone here might know of a few more such issues.

FWIW this web page is one such list of solutions:

http://www.ss64.com/nt/slow_browsing.html

Anyway, I'm sorry if I did annoy or insult anyone. I'm just getting a little frustrated trying to resolve this issue. It seems so silly that I can get files from the other side of the planet at 800kB/s but it takes my own machines the best part of a minute to exchange a directory listing.

Edited by Andrue (Wed 11-Jul-07 15:07:18)

Well, yes, that's true. I was trying to avoid the implication of a slow link being the cause. I think the problem is that either my client or my server are spending way too long in the initial file system querying. Once my client has a file handle throughput is fine. It's that initial directory parse phase that seems to be taking stupid amounts of time.

I don't know how Windows XP occupies its time but I found that whenever I accessed a remote directory many seconds would elapse before the contents were shown. The delay you are seeing is probably caused by the same processing. The solution remains to store the scratch file locally, or accept the delay.

In reply to:

---

it still doesn't sound like either of you have understood my problem.

---

Oh I think I understand the problem alright, so please don't be so presumptious. I merely wanted to ensure that we had covered off the physical network issues before getting into how the Windows file-sharing mechanisms might (or might not) be working.

Have you tried using a packet capture tool such as Wireshark to analyse what conversation is taking place between the client and the server? If so what was the outcome?

Yeah. I finally got Ethereal to capture packets (for some reason it wasn't too happy with my limited user login at first). Something is spamming the remote server with requests to open streams (NTFS and OLE) for every file in the directory. Mostly it's trying to open the OLE SummaryInformation stream but there are others as well.

It's also retrying the requests several times even when the server has responded with OBJECT_NAME_NOT_FOUND.

It might be Explorer loading information ahead of time. I suppose the next call is to go to SysInternals and see what process is making those requests.

Edited by Andrue (Wed 11-Jul-07 20:41:04)