Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a server, dual core, 4GB RAM, running Windows Server 2008 that I use as my main fileserver.

Access to it has all of a sudden become really slow. Whether I'm RDP'd or access files remotely via mapped drives it's just slow!

I can RDP into other machines located in another state over the VPN and they run much faster.

If I am working directly on the server itself it's snappy. Seems that it is something between my client machine(s) and the server.

How would I go about checking the network connection speed between the 2 machines? Or anything else I should check?

share|improve this question

5 Answers 5

up vote 5 down vote accepted

I've seen a lot of little el cheapo network switches "go crazy" in the last year or so. The failure mode is super-slow transfers and packet drops. (I've seen it mainly with LinkSys switches in the last year). I'd suspect that, though not necessarily as the very first thing. Luckily, a simple speed test is pretty easy w/ "File and Print Sharing".

You can do a "quick and dirty" test for file server throughput by creating a large temporary file on your client computer with the fsutil command, and then timing the transfer to the server computer:

fsutil file createnew temp-file-name 209715200

That would create 200MB temporary file. You can do a quick copy w/ timing using the following script (from the directory where you created the temporary file, and assuming you have rights to copy to some share on the server computer):

@echo off
echo.|time
copy temp-file-name \\server-computer-name\share-name
echo.|time

Subtract the ending time from the starting time, convert to seconds, and divide 209715200 by the number of seconds elapsed to get bytes-per-second.

You should see upwards of 7,000,000 bytes per second (roughly 56Mbps) on a 100Base-TX LAN. Anything below that and I'd begin to suspect that something is up. Assuming that the server computer is reasonably modern, it should be able to fill a 100Mbps pipe with no problem. If you're seeing transfer speeds slower than that, I'd start to look at the error counters in the administration interface of the switch that the server and client are connected to. You could have faulty cabling, a duplex mismatch, or NIC driver problems. It's all just a matter of tracking the problem down methodically.


Edit: The file copy test is a nice test because you can conduct it w/o any third-party software. Since you've found a bottleneck does exist, the next step is to identify the bottleneck's cause.

The WSTTCP utility (available at http://www.pcausa.com/Utilities/pcattcp.htm) is a quick and dirty test of your NIC driver and network infrastructure hardware. It sends data that's not coming off disk or being written to disk, so the disk subsystems on the client and server end up being factored out of the equation.

On one machine, execute the following (after you've unpacked WSTTCP!) to "listen" for a connection:

wsttcp -r

On the other machine, execute the following to transmit a test to the remote machine:

wsttcp -t <hostname>

On 100Mbps Ethernet, you might want to modify the transmit command (re-running the receive command on the receiver before you start the transmitter again) to send more buffers, because you'll get slightly more accurate numbers with a longer test:

wsttcp -t -n8192 <hostname>

That will move 64MB of traffic. Increase the "8192" number to send more traffic.

You'll need to either allow the listener thru your firewall software on the listening computer (TCP port 5001, by default) or disable the firewall temporarily.

If you're seeing good transfer speeds with WSTTCP but slow transfers with the file copy, start looking at your disk subsystem (and consider running a hard disk drive benchmark). If the network transfers are still cruddy w/ WSTTCP, keep investigating the network infrastructure, cabling, NIC drivers, or NIC hardware.

Good hunting.

share|improve this answer
    
ok this is good stuff. i'm getting about 1.74 MB/sec. I was also able to check it by just copying a bunch of files via windows explorer - it was suprisingly close to the command line copy. It might be my router - it's a linksys i've had for several years. Could also be cabling as you suggest so i'll check that first. –  Tone Jul 9 '09 at 2:59
    
Yeah, that sounds a bit slow, assuming you're talking over wired Ethernet. I'm dropping an edit on my post w/ some reference to a utility that can help isolate the bottleneck to just the network (cutting out the disk IO subsystems associated with the file copy test I described). The file copy test is nice because you don't need any third-party software to perform it, but it sounds like you need to establish the location of the bottleneck now, –  Evan Anderson Jul 9 '09 at 6:13
    
yes i'm over wired ethernet. today im getting filecopy speeds of ~10MB/sec. I switched the server ethernet cable to a different port on the router and that seems to have helped... so i'm thinking the router is going out on me?? I need to do the above tests as you suggest and see what it tells me - if i find time before travelling next week i'll do so and post back my findings. –  Tone Jul 10 '09 at 17:12

One thing i would recommend is to check for viruses etc. Run netstat to see the open connections and have a look to see if anything is dodgy/unexpected. There are probably tools for testing bandwidth between two windows machines, but I don't know of any. iperf could possibly work within cygwin.

share|improve this answer

Do a tracert command to the destination pc to see where the delay is. This will give you detailed stats about every hop.

syntax eg: tracert 196.12.2.13

share|improve this answer
    
I tried this and i get <1ms –  Tone Jul 9 '09 at 2:14

Something on the user interface (your remote windwos 2008 server desktop) could reduce speed. Maybe some setting, user interface effects. Or some third party software. Anything that moves or is transparent or has color gradients is slower. Squared and single colored portions of the screen are faster.

share|improve this answer
    
Was working just fine before - I haven't changed any settings... so i think it's something with the router or cabling. –  Tone Jul 9 '09 at 2:14

Maybe this is a part of the problem as well?

Remote Differential Compression

share|improve this answer
    
This feature is not checked/installed on my instance. –  Tone Jul 19 '09 at 13:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.