Take the 2-minute tour ×

I want to tune Windows 7 TCP stack for speed in a LAN environment.

Bit of background info: I've got a Citrix XenServer set up with Windows 2008R2, Windows 7 and Debian Lenny with Citrix kernel, Windows machines have Tools installed the iperf server process is running on different host, also Debian Lenny. The servers are otherwise idle, tests were repeated few times to confirm results.

While testing with iperf 2008R2 can achieve around 600-700Mbps with no tuning what so ever but I can't find any guide or set of parameters that will make Windows 7 achieve anything over 150Mbps with no change in TCP window size using -w parameter to iperf.

I tried using netsh autotuining to disabled, experimental, normal and highlyrestricted - no change. Changing congestionprovider doesn't do anything, just as rss and chimney.

Setting all the available settings to same values as on Windows 2008R2 host doesn't help.

To summarize:

  • Windows 2008R2 default settings: 600-700Mbps
  • Debian, default settings: 600Mbps
  • Windows 7 default settings: 120Mbps
  • Windows 7 default, iperf -w 65536: 400-500Mbps

While the missing 400Mbps in performance I blame on crappy Realtek NIC in the XenServer host (I can do ~980Mbps from my laptop to the iperf server) it doesn't explain why Windows 7 can't achieve good performance without manually tuning window size at the application level.

So, how to tune Windows 7?

share|improve this question
add comment

4 Answers

Try enable RSS and TCP Offload Engine:

netsg int tcp set global rss=enabled
netsh int tcp set global chimney=enabled 
share|improve this answer
That's the default on Windows 2008R2, it doesn't help. –  Hubert Kario Feb 3 '11 at 15:32
Try disabling them. –  joeqwerty Feb 3 '11 at 15:39
disabled, enabled no difference –  Hubert Kario Feb 3 '11 at 15:43
add comment

It could be a different network driver in Windows 2008R2 vs Windows 7. Also, does xenserver always provide the same virtual nic to Windows 2008R2 and Windows 7? Because if it's different then a different driver will be loaded.

There may be some performance differences.

EDIT: I just remembered that windows 7 by default has very small send/receive buffers. In some app's I was developing I found that under windows 7 it was something pathetic like 8kB. Under ubuntu linux it's around 120kB. You may read somewhere that the limit is 64kB. This is actually incorrect for later versions of windows. I've found it can be set to even as high as 1MB and beyond. Although little performance increase will be noticed when it's this large.

This link provides some tcp tuning parameters in the registry that apply system wide. Be aware that many of those options can be overridden by applications themselves.

http://www.psc.edu/networking/projects/tcptune/ http://www.psc.edu/networking/projects/tcptune/OStune/winxp/winxp_stepbystep.html

Try increasing the window size and send/receive buffers. Hopefully those registry settings in the link still apply in windows 7.

share|improve this answer
Then why if I set larger TCP window the speed increases? And no, XenServer doesn't change the presented NIC. –  Hubert Kario Feb 3 '11 at 16:34
I was only addressing that this might be a reason. I'm a developer and I happen to be developing an application that's pushing loads of data at near gigabit speed. However, developing on virtualbox I discovered performance differences with different nic drivers. Yes, increasing TCP window will increase throughput because there will be less ack return packets. Have you shut down all the other VM's in Xen to ensure that windows is the only one using it? –  Matt Feb 4 '11 at 0:56
My usual usage of network on the Xen host is below 60-90KiB/s. And checked the driver, it loads the same one. As a side note, Xen and Virtualbox are completely different hypervisors, one is type 1 the second is type 2. Besides, I've seen the same performance problems with bare-metal installs. I mainly mentioned virtualization to rule out hardware problems. –  Hubert Kario Feb 4 '11 at 9:05
I just remembered something. Details in main answer. –  Matt Feb 5 '11 at 3:52
add comment

TCP Autotuning (which you're already ruled out), MTU which has already been addressed and MMCS (Multimedia class scheduling) are usually the big differences. Since MMCS hasn't already been addressed, take a stab at disabling it.

Do ensure that your tcp window autoscaling is disabled if you're at or near LAN speed.

Instructions are available here: http://smallvoid.com/article/winnt-services-mmcss.html

share|improve this answer
I'm not sure if I did change it (as it has been over 6 months since) but it looks promising, I'll try it tomorrow. –  Hubert Kario Sep 6 '11 at 21:44
Didn't help by much, made the performance about 10-20% better. –  Hubert Kario Sep 8 '11 at 17:19
add comment

MTU? http://networking.nitecruzr.net/2007/11/setting-mtu-in-windows-vista.html

share|improve this answer
default, at 1500 –  Hubert Kario Feb 3 '11 at 16:33
add comment

Your Answer


