Hi all, As we all know previous versions of Windows Server haven't worked to well with TCP Offloading, TCP Chimney, or just allowing the network card to handle anything TCP Stack related. This problem isn't because of Microsoft solely however device drivers have also been poorly written to support this functionality. As a software manufacturer for a large financial firm speed and overall performance are critical, along with testing of new operating systems. Reason for the post is mostly looking for any advice from fellow tech people on what network cards they find work best with the various TCP related functionalities? Any help would be much appreciated. Thanks, Sean

Tested Broadcom cards based on 5706/5708 chip. This includes all network adapters on motheboards of Hewlett Packard Proliant servers (the most sold servers worldwide), also separately sold HP network cards (NC380T, NC373T).None found to be working. Trying to use TCP offload will definitely lead you into stability problems. Notice that HP recently put many notes throughout the documentation, that TCP offload is not supported in Windows 2008. Tried to get support - answer from HP is that withWindows 2008 TCP offloadis not supported. This functionality works "only on paper".The requirements to write the offloading driver are so complex that probably stabledriver will never be written. Driver files to are larger than all Windows 98....Maybe in Windows Server 2011 or so, with new 10G chips will be more push from the users to implement offload. Currently the safest solution is to add additional processor.

This Alacritech tax for OEMs to implement TOE is inhibiting adoption. Until that gets fixed, TOE adoption will continue to be slow.

Hewlett Packard just released "HP Proliant Networking Software 9.50", which contains network driver 4.6.17c, and network configuration utility 9.50. From the first look everything is finally implemented in this version. TCP offload can be enabled and netstat -nt shows TCP sessions are offloaded in Windows 2008. To be enabled, TCP offload must be enabled BOTH via network adapter (driver) properties (in HP case this can be done in HP Network Configuration utility) andalso on OS level with the following command:netsh int tcp set global chimney=enabledenables the offload.netsh int tcp show globalshows the offload setting in the OS.TCP offload looks beneficial also from the "green" point of view - offload decreases the load on main processors so they run cooler (and cheapier) even if application is not utilizing the processors fully.We are loosing money for electricity if we are not using TCP offload - andwe paid for it, according to server and network adapter specifications.But the driver that enables offload was delayed more that one year until this 9.50 release at Feb 2009. As I have no reason for trust the drivers quality based on previous experiences, I decided to test it under heavy load in HP Proliant DL385G2 server with built-in multifunction adapter that supports TCP offload (Broadcom 5706 chip). After running about three days with thousands of TCP sessions offloaded from different IPs under constant FTP type load (traffic was about 300Mbit/s), unfortunatelly, server lost both network adapters at all (message "no active network adapters" was snown in Task Manager Network tab, ipconfig command just displayed the header line and returned back to the command prompt). Trying to restart the server resulted in Blue Screen after long display of "Shutting down...." message.So, not yet stable with many TCP sessions, i.e. public very high load FTP server case. On other server with less load serverstill runs OK after two weeks of enabling TCP offload.I now testing if the same server with same load will run stable without TCP offload with the same 4.6.17c driver version. Nothing changed just "netsh int tcp set global chimney=disabled" was issued before reboot when network adapters dissapeared.Preliminary resume: For Broadcom 5706 multifunction chips, with driver 4.6.17c TCP offload not yet stable under heavy network traffic loads.I will wait for the next HP/Broadcom driver version, and then try the load test again. More than one year wait for the stable Broadcom offload drivers still continues.

hi guys,to add comment to the above post, as mentioned earlier microsoft is not soley responsible for entire TCP communication, but the NDIS is provided by microsoft which they incorporate the functionality of tcp chimney which vendors / NIC vendors should take the advantage.NDIS 6.0 supports an architecture for full TCP offload. This architecture is called a "chimney offload" architecture because it provides a direct connection, called a "chimney," between applications and an offload-capable NIC. The chimney enables the NIC to perform TCP processing for offloaded connections, including maintaining the protocol state. The chimney offload architecture reduces host network processing for network-intensive applications. This allows networked applications to scale more efficiently while also reducing end-to-end latency. Fewer servers are needed to host an application, and servers are able to use the full Ethernet bandwidth. The TCP chimney offloads all TCP processing for one or more TCP connections. The primary performance gains are obtained from offloading segmentation and reassembly (SAR), offloading processing that ensures reliable connections (for example, ACK processing and TCP retransmission timers), and reducing interrupt loading. Note The Windows Vista operating system continues to support the individual TCP task offloads available in earlier versions of the operating system. These tasks can be offloaded on connections that have not been offloaded through a chimney. An offload-capable NIC should support both chimney offloads and task offloads. Such a NIC provides the highest degree of offload optimizationquestions=======a) have you guys tested the tcp chimney functionality with an application / networking application ?your observation is correct , when you enable tcp offload, the networking subsystem is offloading its task to network driver, but if the driver is non capable enough handling the request , its of no use using those NICbut i have gone thorugh many links of broadcom and HP and even from microsoft website which claims that these vendors supports TCP chimney offloading feature. When microsoft confirmed, then they would have tested the functionlaity , i really wonder are we testing the applicatin in right way sainath Windows Driver Development