Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have for years connected to a small set of servers via Remote Desktop (currently, Win7 client, Win2008 R2 servers). Performance is the equivalent of being directly connected. The client machine is not in the network, but I connect via IP and use network credentials.

Recently, I built a new server (to host Hyper-V), and then a new workstation (Win 7) to manage it and develop on it. This is all on the same network segment as the previously mentioned servers and client.

The new client connects easily to the new server, but latency is so bad that it can take 5-15 seconds for any mouse or keyboard action to be seen and implemented on the server. Trying the other Win7 client exhibits the same behavior. Using the new Win7 client to access the previously mentioned servers behaves identically with the other Win7 client--perfectly. Therefore, whatever the problem is, it is associated with the new server.

This problem is not unknown throughout the web world, and I have found both client-based and server-based fixes. Although tried, the client-based fix (changing AutoTuning values) does not work, nor does the server-based fix (disabling task offload).

Any other recommendations?

share|improve this question
My rating (whatever it is) by no means reflects all instances of my presence on these "Stack Overflow" sites. I've given up trying to understand how it works. – Michael Broschat Apr 18 '11 at 22:36
on this site, Server Fault, you have asked 6 questions. Before yesterday you had not marked any of the answers under those questions as accepted. If you did not get any acceptable answers, perhaps rewording the question might help. If you found the answer yourself, you can answer your own questions too. Part of being in a community is give-and-take; marking questions as answered enhances the community and rewards the person who put the time into writing a correct answer. – Chris S Apr 19 '11 at 12:23
up vote 0 down vote accepted

Disable large send offload on the server nic.

share|improve this answer
Any details on how this would affect RDP lag? – Chris S Apr 18 '11 at 12:46
It resolved the same issue for me. – Greg Askew Apr 18 '11 at 13:56
This was it. Or, rather, it worked. I suspect that TomTom is correct, and the driver for (in my case) a Marvell controller is not up to snuff. Eventually, I can put an Intel controller into the machine and try that, but right now I'm so happy that disabling Large Send Offload worked, that I don't want to rock the boat. – Michael Broschat Apr 18 '11 at 22:29
Once again, for anyone just finding this post: 1. From Device Manager, find your network adapter. 2. Find the Advanced tab of Properties. 3, Dial the property called Large Send Offload (IPv4), and choose 'Disable' from the Value dropdown. – Michael Broschat Apr 18 '11 at 22:31

Undo all your changes. Fix the driver situation on the server. This is NOT a configuration issue. It is crap happening on the network by your server. This COULD be outdated drivers, it COULD be defective drivers. Seen this and worse from drivers not able to calcualte an IP checksum but having drivers that are configured to do so.

Post the hardware of the Network Interfaces and we can give you a hint where to find drivers. Alternatively next time you purchase a server get an Intel network card and install current drivers. There is a LOT of bad things one could say about them (cost being one), but they WORK. As in: WITHOUT PROBLEMS. As in: Intel seems to hire the last people on the world capable of creating network drivers for windows.

share|improve this answer

There were some latency issues with HyperV of Windows 2008R2.... some of my customers upgraded to Windows 2012 or 2012 R2 and had a dramatic improvement in network stability from RDP clients to HyperV guests. Probably that has something to do with the integrated virtual switch.

And about the hardware problems of the host - I found that the Intel Pro series but also the desktop Gbit Adapters from Intel do fine with HyperV of any version, but on my whitebox the Broadcomm ethernet on the mainboard was not able to provide stable connections to RDP sessions on HyperV guests of any version.

share|improve this answer

Your Answer


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.