We recently ran into a case where connecting to a Windows Server 2003 server with SQL Server installed on it, some clients were quick and some were not. Packet traces actually showed a five second delay in the communications of those clients with issues. The delay was at the server. The server in question was Windows Server 2003 SP2. As we started looking at the clients, we noted that the ones not having issues were the older Windows Server 2003 systems and Windows XP workstations. Windows Server 2008 servers where a connection was being initiated from or Windows Vista/7 workstations were the ones having the issue. As a result, we pinpointed the problem to be with the fact that TCP Chimney Offload, Receive Side-Scaling, and Network Direct Memory Access (NetDMA) were turned on. Here are some articles that deal with how to turn them off:

•  An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers
• Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008

Basically, all three of these technologies try to offload some of the burden of managing network communications from the CPU to the NIC. Basically you're offloading some of the work to dedicated hardware in order to increase performance. This is similar to offloading graphics functions to a dedicated graphics card. However, in some cases you see the exact opposite effect. In our environment we've seen it several times and our default now is to turn them all off. By default, the Windows Server 2008 operating system does turn them off. But there are two places where they can be turned off:

• The operating system itself (which those links above walk you through)
• The NIC (usually covered by the Advanced tab of the NIC properties)

There's this nice little blurb from the Windows Server 2008 knowledgebase article:

TCP Chimney Offload will work only if it is enabled in both locations.

However, in a recent engagement with Microsoft, we were advised to make sure this setting was off in both locations. The other settings don't say if they have to be off in both places, but if we're turning TCP chimney offload off in both places against what the KB says is required, I would err on the side of caution and turn off these settings at both locations, too. It only makes sense. One of the things we experienced was when we updated the drivers for the NIC, our settings for these three technologies flipped back to on. This is the default for the OEM of the NICs we were using. Therefore, don't rely on having them off at the NIC. Make sure they are also off at the OS level. And if you're doing a driver/firmware update on the NICs, verify the settings don't change on you.