RSS / TCP Offloading strikes again. Microsoft should KILL this feature for the masses…

Hi All,

 

This is more of a rant than anything….      but I would love other peoples thoughts.

 

Today, in my own office, a Intel NIC driver was installed on a Windows 7 PC.    This driver enabled RSS, TCP offloading etc.    I got a call to tell me that once again access to the Companyweb was slow on SBS and that typing in http://companyweb in Office products paused for 30 second or more before showing the site content.

 

This symptom has taught me to first look at the network card settings and disable TCP offloading features, which sure enough fixed the problem.

 

My question is this…

 

WHY is this feature even available in Windows / Network Card drivers when I cannot find even ONE common situation where this feature has helped a network or server?

 

Seriously….   Why don’t Microsoft simply turn this feature off by default in an update to ALL versions of Windows and block drivers from enabling it without a user input?   

 

Over the past years I get more calls on support to our office that related to this supposedly great feature than anything else.    On top of that, I would say that there must be millions of people out there that do not even know why their servers are slow, PC’s are slow and network copying slow……

 

Rant over…

 

Gaaaaah!

  7 Replies to “RSS / TCP Offloading strikes again. Microsoft should KILL this feature for the masses…”

  1. Bob
    February 23, 2010 at 9:46 am

    Nick, this may be an old problem to you, but I’ve never heard of this and may be having this issue. Can you describe in detail what I need to disable and where? Is this server side or should this be disabled on the client NIC too? We are having this on a SharePoint 2007 server, is this only an SBS issue?

    Thanks

  2. NickWhittome
    February 23, 2010 at 10:22 am

    In your network card settings, Intel and Broadcom primarily; you need to disable the advanced features.

    Receive Side Scaling (RSS Offload)
    TCP Offload (IPV4 and IPV6)
    IP Checksum Offload

    This problem has been around for ages, and was made worse since 2003 SP2 was released.

    A couple of good articles:

    http://support.microsoft.com/kb/948496

    http://blogs.technet.com/fixit4me/archive/2009/01/19/disable-rss-and-tcp-offload-fix-it-live.aspx

    Fixit packs… wonderful, but this should be included in the critical updates IMHO. As they say….

    Its a bitch!

  3. (The other) Nick Whittome
    February 23, 2010 at 4:58 pm

    Nick

    I don’t disagree with your rant in principle…but two questions

    1. Your rant is primarily directed at Microsoft. Surely it should be directed more at Intel & Broadcom who write the drivers for their cards?

    2. The issue (and Microsoft’s suggested fix) seems to be regarding the parameters on the server nic rather than the client nic. You imply (as you did this on a Windows 7 PC) that the fix should be applied to clients that see this issue. Is this the case??

    cheers

    Nick

    P.S. and yes….it’s getting silly the two of us with identical names both working in IT. I keep getting congratulated on the articles you write. Hopefully you are not getting abuse for the rubbish that I write. ;-))

  4. NickWhittome
    February 24, 2010 at 8:24 pm

    Hey the other Nick. Yes, the mixup on us two has been both ways! It seems you and I simply need another Nick Whittome, and we could sit on each of his shoulders. One in a Devil Suit the other and Angel…. you choose 😉

    The RSS / TCP Offloading / Anything offloading problem affects everything. Desktops, laptops, servers. It can break, slow down, appear to function – then not. You get the idea.

    The rant is at Microsoft, because they have the ability to make these option “off” by default. This should be treated the same way as the infamous EnableOpLocks key… it should be an option, that people who want to do advanced things, can…. But those of us that want a solid, stable, quick enough network (95% of us) we get that 🙂

    There you go…. you started me ranting again 😉

    Nick

  5. NickWhittome
    February 26, 2010 at 1:15 pm

    You see… I am not the only one…. just seen this:

    http://blogs.msdn.com/psssql/archive/2010/02/21/tcp-offloading-again.aspx

  6. March 3, 2010 at 11:56 am

    I am totally with you.
    I have been disabling this feature on Windows Servers and various application server roles since the feature first appeared in 3Com NICs back in the days of NT 4.

    In the virtualization world this came to a head again with Hyper-V – as VMs also suffer (but can simply disable it at the host and affect all your VMs – 😉 )

    I know of SQL and Exchange, and Terminal Services (RDS) admins that just do this as regular practice as these are primary application roles that benefit.

    The net problem is data flow – with TCP Task Offloading options turned on the network traffic happens in bursts instead of a nice smooth constant stream – the result is that many applications and clietns cannot handle this properly, thus the user experience is a slow down.

    I know that MSFT blames the NIC vendors – but gee whiz, this has been around for a really long time.

  7. Rob Pelletier
    May 6, 2010 at 8:16 am

    OK, so this TCP Offload business seems be more complicated than this:

    On the Host machine, the network adaptor has both the “normal” network connection and a shadow of it, with “- Virtual Network” at the end of its name.

    I assume we disable anything with the word “Offload”, or maybe anything involving “TCP” and “Offload” on either one or both of the NICs. And maybe the same thing with the guest machine?

    Why not just do the registry hack that we see bandied about:

    HKLM/SYSTEM/CurrentControlSet/Services/TCPIP/Parameters
    DWORD (32-Bit)
    DisableTaskOffload = 1

    Wouldn’t this cover everything?

    See what I mean? Complicated!

Leave a Reply to NickWhittome Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.