The secrets of TCP Chimney offloading

By | April 2, 2008

Some time ago, about a month or so, we had a problem with our SQL Server 2005 running on Windows 2003. What started happening was that the scheduled jobs were failing due to many connections errors. After some searching I found out that the errors could be caused by the TCP/IP chimney offloading. This gets installed with the ‘Scalable Network Pack’ of Microsoft.

One of the things I tried to fix the problem was disable it but this caused even more trouble.

Let me first explain what this protocol is. As of the later versions of windows servers the OS offers the capability to let TCP/IP processing be handled by the network card. Which in theory should increase the network speed and decrease the CPU load, read this article for some more on this.

As I already stated I had to disable this technique because it was causing some network problems between the live SQL servers and the internal backup server. It effectively blocked us from replicating data to the internal servers.

After disabling this in Windows the problems with the network were gone. No more mysterious network time-outs or failed transactions. But like the MSDN article already predicted we started having serious network speed issues. The weird part was that those jobs slowing down went over the loopback interface. This meant that the OLAP calculations slowed down significantly.

To make matters worse the past four days or so these issues resulted in no longer being able to calculate some cubes and dimensions. A cube that cost a little under 10 minutes to process before now took over an hour. And as some of you might now the default timout limit for OLAP is exactly one hour. Causing the cube to fail in a timeout.

Off course this is not acceptable. At first I did not know that disabling the chimney offload caused this problem. But that became painfully obvious after enabling it again and running the processing again. All of a sudden all cubes processed succesfully and quick!

Now I have left the feature on but that still leaves me with the initial problem of network issues. Let’s hope it doesn’t rear its ugly head again. But if it does I’m going to have to try other things like changing network cards or drivers.

Update 1:
After some looking I found the original page that helped me to disable the TCP-IP chimney based on the error I got from SQL Server.  The exact error I got was

System.Data.SqlClient.SqlException: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 – An existing connection was forcibly closed by the remote host.)

To visit this page click here.

2 thoughts on “The secrets of TCP Chimney offloading

  1. pasti

    Can anybody tell me if this error has something to do with TCP Chimney Offloading?
    Error : Unable to read from the input stream.Session will be truncated

    Reply
    1. Jongerius Post author

      It doesn’t sound like the issue’s related to TCP Chimney offloading. The errors usually are about the TCP pipe being closed prematurely. What you are describing sounds like truncation of data (accuracy loss).

      This could happen if you try and put a varchar(200) into a varchar(100), causing data to be truncated.

      Reply

Leave a Reply