 




<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Receive window shrinking</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/receive-window-shrinking/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/receive-window-shrinking/</link>
	<description></description>
	<lastBuildDate>Sun, 19 May 2013 03:14:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: hefy jefy</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/receive-window-shrinking/#comment-54159</link>
		<dc:creator>hefy jefy</dc:creator>
		<pubDate>Wed, 25 Jun 2008 04:33:15 +0000</pubDate>
		<guid isPermaLink="false">#comment-54159</guid>
		<description><![CDATA[Not very informative - ( I am feeling my way a bit) here&#039;s a bit more information:

I need to figure out why a TCP link we use is failing. The TCP link streams data from an instrument to a logging system continuously over a dedicated NIC pair.  The data volume is quite high although in general the Network usage rarely exceeds 10% (of a Gigabit link).

I have installed and run Windump successfully and I am able to see what happens immediately prior to the failure.

The failure always occurs eventually, but sometimes only after many hours. On every occasion I notice that even whiel the link is &quot;up&quot; the TCP receive window size varies  from the  default maximum  up and down  sometimes dropping very low (104) and usually recovering.  But at some point the size drops to zero at which point the instrument stops sending and goes into &quot;persist timer&quot; then all I see is occasional (60 secs) requests from the instrument to the logging system; each time the logger responds with recieve window zero so the connection is effectively dead.

Simply going online and online at the logging end restores the connection.

The programmers I work with seem not have many ideas about this problem so any help is much appreciated.]]></description>
		<content:encoded><![CDATA[<p>Not very informative &#8211; ( I am feeling my way a bit) here&#8217;s a bit more information:</p>
<p>I need to figure out why a TCP link we use is failing. The TCP link streams data from an instrument to a logging system continuously over a dedicated NIC pair.  The data volume is quite high although in general the Network usage rarely exceeds 10% (of a Gigabit link).</p>
<p>I have installed and run Windump successfully and I am able to see what happens immediately prior to the failure.</p>
<p>The failure always occurs eventually, but sometimes only after many hours. On every occasion I notice that even whiel the link is &#8220;up&#8221; the TCP receive window size varies  from the  default maximum  up and down  sometimes dropping very low (104) and usually recovering.  But at some point the size drops to zero at which point the instrument stops sending and goes into &#8220;persist timer&#8221; then all I see is occasional (60 secs) requests from the instrument to the logging system; each time the logger responds with recieve window zero so the connection is effectively dead.</p>
<p>Simply going online and online at the logging end restores the connection.</p>
<p>The programmers I work with seem not have many ideas about this problem so any help is much appreciated.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 6/9 queries in 0.018 seconds using memcached
Object Caching 268/271 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-19 05:50:41 -->