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

Update

Ok, I've tried the answers below and nothing has changed. I've identified the chipset in the laptop as the NVIDIA nForce 520. I downloaded the latest Vista x64 drivers for the nForce 520 (NVIDIA doesn't have any drivers for that chipset for Win 7 yet). I've tried installing the included firewall software (thinking maybe it is interfering - it's not). I've completely uninstalled my anti virus software (I am using Avast!) thinking its network filter driver may be causing a problem, that hasn't helped either.

I took my laptop over to my brothers house and was able to copy files at 10 - 12 MB/s over his 100Mbit network so I don't think it's the hardware.

I have run iperf with some surprising results:
iperf from the laptop sending to the server (upload)

> iperf -c naru
------------------------------------------------------------
Client connecting to naru, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[328] local 192.168.7.100 port 8549 connected with 192.168.7.6 port 5001
[ ID] Interval       Transfer     Bandwidth
[328]  0.0-10.0 sec   162 MBytes   136 Mbits/sec

> iperf -c naru -w 64k
------------------------------------------------------------
Client connecting to naru, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[328] local 192.168.7.100 port 8550 connected with 192.168.7.6 port 5001
[ ID] Interval       Transfer     Bandwidth
[328]  0.0-10.0 sec  1.06 GBytes   909 Mbits/sec

iperf from the server sending to the laptop (download)

> iperf -c miyuki
------------------------------------------------------------
Client connecting to miyuki, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[256] local 192.168.7.6 port 51871 connected with 192.168.7.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[256]  0.0-10.1 sec  25.2 MBytes  20.8 Mbits/sec

> iperf -c miyuki -w 64k
------------------------------------------------------------
Client connecting to miyuki, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[256] local 192.168.7.6 port 51872 connected with 192.168.7.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[256]  0.0-10.0 sec  21.1 MBytes  17.6 Mbits/sec

For comparison here are the iperf numbers between the HTPC and the server

Server: Naru, Host: CC (CC sends to Naru)
iperf -c naru:        0.0-10.0 sec   363 MBytes   305 Mbits/sec
iperf -c naru -w 64k: 0.0-10.0 sec  1.06 GBytes   912 Mbits/sec

Server: CC, Host: Naru (Naru sends to CC)
iperf -c cc:        0.0-10.0 sec   322 MBytes   270 Mbits/sec
iperf -c cc -w 64k: 0.0-10.0 sec  1020 MBytes   855 Mbits/sec

Using wireshark to watch a transfer from the server to the laptop nets a lot of the following entries:

(:51aa is the server, :37a1 is the laptop)
No.   Time      Source                    Destination               Proto Info
37785 27.286240 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#13] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40517974
37786 27.286258 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#14] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40519414
37787 27.286277 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#15] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40520854
37788 27.286295 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#16] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40522294
37789 27.286313 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#17] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40523734
37790 27.286332 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#18] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40525174
37791 27.286351 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#19] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40526614
37792 27.286370 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Previous segment lost] [TCP segment of a reassembled PDU]
37793 27.286372 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP segment of a reassembled PDU]
37794 27.286375 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Fast Retransmission] [TCP segment of a reassembled PDU]
37795 27.286377 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37796 27.286379 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37797 27.286382 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37798 27.286413 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#20] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40529494 SLE=40499254 SRE=40526614
37799 27.286432 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#21] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40530934 SLE=40499254 SRE=40526614

At this point I am at a complete and utter loss as to what to try next.

Original Question

Background

I am currently experiencing an issue on my freshly installed Windows 7 laptop. The issue originally occurred after I had installed the Windows 7 RC. When Windows Vista and the Windows 7 Beta 1 were installed on this laptop I was able to transfer at gigabit speeds with Jumbo frames turned on to the 9KB/9014 range. The two switches between the laptop support Jumbo frames as well.

When copying files from my server to my laptop, they run at a snails pace (usually less than 1 MB/sec) while other devices going through the same switches can transfer at higher speeds (45 - 55 MB/sec). It seems copying from the laptop to the server nets a faster speed but nothing like it should be.

Machines involved

  • Miyuki: Laptop with the issue. Windows 7 x64 RTM. HP Pavilion dv9700 CTO. Uses a NVIDIA nForce 10/100/1000 Mbps Ethernet adapter. (Video is GeForce 8400M GS)
  • Naru: Server with files. Custom Windows Server 2008 R2 x64 SP2. Uses a D-Link DGE-560T PCI Express Gigabit adapter.
  • CC: HTPC on same switch without issue. Windows Vista x86 SP2. Uses an on-board Realtek RTL8168B/8111B PCI-E GBE adapter.

When these images were taken jumbo frames have all been turned off.

The images

Copying initiated from the laptop

Server -> Laptop

Laptop -> Server

Copying initiated from the server

Server -> Laptop

Unexpectedly having the server copy a file from the laptop to itself results in speeds I would expect. (Laptop -> Server)

I stated earlier that the other machine on the same switch doesn't have this issue. High DPI is turned on since this is displayed on a HDTV.
Server -> HTPC

Naturally as a test I decided to see what the speeds were between my laptop and the HTPC. Unfortunately they were exactly what I expected.
HTPC -> Laptop

Final notes

I have tried everything I can think of. Even jumbo frames are turned off at this point and nothing seems to affect it. I've tried turning my Anti-Virus protection off to changing the cables that I use. Currently all cables in use are CAT-5e that I have built. I tried taking the cable from the HTPC and plugged it into my laptop to see if cabling was an issue. The two switches in question are a D-Link DGS-1216T and a "dumb" switch that supports jumbo frames, the D-Link DGS-2208.

share|improve this question
1  
did you tried tool like iperf (google for iperf win32) to measure available bandwidth?if iperf gives reasonable speeds maybe its new drm invention :/. i doubt it - but its worth checking otherwise double check if there is no duplex missmatch. –  pQd Aug 8 '09 at 23:50
    
Have you tried something like pscp to a nearby server to see what speed you get with that? –  chris Aug 9 '09 at 16:50
1  
Have you tried cross connecting the server and laptop together so that there is no switch between them? –  Joseph Nov 4 '11 at 19:10
    
Amen to what @Joseph said. Please try eliminating the switch from the equation. –  Jeremy Visser Nov 9 '11 at 11:47
add comment

14 Answers

Try disabling Window's auto-tuning feature.

In a CMD window:

netsh interface tcp set global autotuning=disabled 

Re-run your test, and see if you notice a performance improvement. I've had to do this on a couple of laptops running Windows 7 in my house, and it's helped.

If things get worse, or you don't notice any improvement, you can re-enable autotuning by:

netsh interface tcp set global autotuning=normal
share|improve this answer
add comment

To verify whether the laptop is not at fault, run up an ubuntu live cd, install iperf onto the ramdisk and run a test.

This should at least test the network side of it.

share|improve this answer
add comment

This seems to be a big issue with Windows 7. Several gamers have complained about this issue.

  1. From a command prompt (usually in All Programs -> Accessories -> Command Prompt) run “regedit”
  2. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces
  3. Browse the items under interfaces until you find one that has an IPAddress entry matching the network interface you want to affect (typically LAN IP addresses start with 192.168 or 10.0); note that if your IP address is automatically assigned by a DHCP server you may need to look for a matching DhcpIPAddress instead of IPAddress
  4. Right-click on the interface and select New > DWORD (32-bit) Value, name it “TcpAckFrequency”
  5. Right-click the new TcpAckFrequency value and select Modify, enter “1″ (Hexadecimal radio button should be selected)
  6. Right-click on the interface and select New > DWORD (32-bit) Value, name it “TCPNoDelay” (note that TCP is all uppercase this time – that’s intentional)
  7. Right-click the new TCPNoDelay value and select Modify, enter “1″ (Hexadecimal radio button should be selected)
  8. Verify that both TcpAckFrequency and TCPNoDelay now show up in the adapter’s property list with types REG_DWORD and values 0×00000001
  9. Exit regedit and reboot (reboot is necessary for the changes to take effect!)
    1. Play a game and enjoy your new low ping

This decreased my ping in most games from 200-300ms to 50-60ms, which matches the latency I would see via a tracert to the game’s server.

Taken from reduce game network latency in windows 7 or vista

share|improve this answer
1  
tracert use ICMP, not TCP. These keys are for TCP, so they change nothing for ICMP. Don't know why you saw better response time through tracert –  Mathieu Chateau Aug 9 '09 at 13:05
    
Well, I went ahead and tried this and it still seems to be the same. I am updating the original question with more information and things I have tried. –  Joshua Aug 12 '09 at 2:05
1  
Matthieu, he didn't say he saw better time from a tracert. He said that latency in-game becomes equivalent to a tracert, meaning that the latency observed in TCP traffic is similar to that of ICMP traffic, which was functioning normally. –  MDMarra Aug 12 '09 at 3:01
add comment

Check for dropped packets. Not sure how to do this in windows, but if you have a linux machine you can check there.

I had a similar experience with a gigabit switch where the gigabit mode was broken and dropping packets. I only saw trouble when I had 2 machines connected in this mode. In 100K mode, everything was fine. It was a nasty problem which took me a few days to find out. I might have been a D-Link. Do some googling about your model of switch. I did and found others had the same problem as me.

share|improve this answer
add comment

I've come across this before with other AV products. My issue was with SMB and the AV product interfered even when "disabled". It showed similar results in wireshark that you have. Here is one of the many sites I checked to arrive at the root cause: Symantec SMB issue and another: SMB2 fail with NTP

Additionally, you might try disabling/changing all or some of the settings within SMB. I would even consider disabling v2 on the OS. Check this article that describes an SMB issue within Win Vista and this link to Microsoft outlines some tech data about SMB reg settings.

I know you mentioned Avast, but it's fairly coincidental that I saw similar wireshark results. Note that everything but file transfer seemed to work fine in my case.

share|improve this answer
add comment

I've had problems with clients communicating with Windows Servers when using Packet Signing. I didn't experience slowness, but rather very common connection drop-outs.

Read here for the solution that fixed my problem.

Also I don't see any suggestions here for turning off TCP Chimney functions one by one to see if one of them has gone awry.

share|improve this answer
    
Been burnt by this too... –  Ben Campbell Nov 10 '11 at 2:15
add comment

It seems like the o.s. is checking the packets before writing to disk. I observed all the slow transfers are the ones which try to write to laptop... I suggest

  • checking block sizes of the partitions on laptops hdd (small block sizes can cause a bad seek time for free space when trying to trasfer a single big file (or so))
  • checking any firewall policy that checks incoming packets for disk write
  • checking any file activity monitor (this should be out of concern due to you uninstalling antivirus) (as you know avast do live file checks and that slows network transfer a bit..)
  • defragmenting target partition (again about seeking for free space)

Others are suggested and didnt seem to be helping:

  • auto-tunning
  • duplex level
  • cables...

One last suggestion is, Can you check battery mode link detection on advanced properties of nic? It's a laptop and there could be some issues with power saving properties... Try "No Energy Saving" on battery mode link detection, and "Full" on battery speed settings.

I am using win7 on a desktop pc and those options are not included in my nic's advanced properties. As long as I had never gone through with this issue you can check the values of "Flow Control" to "TX and RX Enabled" as my nic's options, too. Jumbo is disabled, Speed and Duplex is also auto on my config...

I can't think of any other solution... Hope this helps...

share|improve this answer
add comment

By everything, I assume you've set the network cards to full-duplex, 100MBit, and not auto?

share|improve this answer
1  
+1 for "not auto" :) –  dimitri.p Aug 8 '09 at 23:57
    
Yup, I've tried all of the variants my card supports... 10 half, 10 full, 100 half, 100 full, and 1000 full. None of those affected it in any way and according to the switches they do negotiate at 1000 full. –  Joshua Aug 9 '09 at 0:22
10  
Never do that if the switch is not manageable. If you are forced full duplex on one side but auto on the other side, the other side becomes half duplex. Then you start loosing packets (much...). Switch that you can't manage are auto. Keep auto on your server and check that the interface negociated full duplex. Check for interface errors too. –  Mathieu Chateau Aug 9 '09 at 13:04
4  
-1 for "not auto". You need the same config at both ends (switch and NIC) including auto-negotiate. –  dunxd Nov 3 '11 at 20:18
5  
I am curious, have you tried removing the switch from the equation and running a crossover cable from the "server" directly to the "laptop"? –  SpacemanSpiff Nov 4 '11 at 19:13
show 5 more comments

You will probably hate this answer, but I have to say it!

Have you tried updating the drivers?

I get a similar problem on my laptop (Realtek based NIC), it transfers at around 3MB/s but then the moment I upgrade the drivers to the latest ones from their site it goes up to around 40-50MB/s

Just because the drivers with Windows work, it doesn't mean they are best.

share|improve this answer
    
Haha, yeah, that was actually the first thing I've tried. Right now I'm back on the in-box Windows 7 drivers but I have tried the latest nvidia ones as well. The only drivers I haven't tried are the ones from the Windows 7 beta or Vista. –  Joshua Aug 9 '09 at 1:59
    
Try the Vista ones and see how that pans out. I had several minor issues that have been fixed in updates for Win7 now; I manually fixed by installing Vista drivers for hardware. –  Dave Rickman Aug 12 '09 at 3:23
add comment

I would suspect that it's something on the path from the server to the laptop, e.g.:

  • Switch port patched to laptop
  • Ethernet cabling or connections between switch and laptop

Per @SaucemanSpiff's excellent suggestion, have you tried cabling the laptop directly to the server using a known good CAT5E or CAT6 cable? There is no need for a special crossover cable as long at least one of the interfaces involved supports Gigabit Ethernet (which implies Auto MDI-X).

share|improve this answer
add comment

if it is due to changing the OS, then surely problem lies in the OS. you should try to install latest windows 7 service pack and keep windows updated with latest updates. and hope for the best

share|improve this answer
add comment
  1. You've beat the PC to death with updates and tested it offsite without failure. Have you tried doing updates and such on the SERVER "naru"?

  2. Most of the solutions in this thread suggested by others could apply to the server, have you tried them there?

  3. What happens when you test using Robocopy (with and without jumbo)? If it is fast in both directions then I would use netshark to look at the SMB session headers at the beginning of the copies in each direction and see if something looks different in the naru->miyuki setup.

share|improve this answer
add comment

Have you tried using teracopy? I've been using this as a standard replacement for windows copy for over a year now, and it has shown improvements in transfer speeds :)

share|improve this answer
add comment

Kind of a shot in the dark but it could help.

  • Disable "Remote Differential Compression" in Control Panel - Programs and Features - Turn Windows features on or off.
  • Remove IPv6 from network properties. Do you use IPv6 in your LAN? If not disable it.
  • Clear DNS Cache with ipconfig /flushdns on the CLI.
share|improve this answer
add comment

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.