<?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: Linux Increasing The Transmit Queue Length (txqueuelen)</title> <atom:link href="http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/feed/" rel="self" type="application/rss+xml" /><link>http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/</link> <description>Every answer asks a more beautiful question.</description> <lastBuildDate>Fri, 10 Feb 2012 19:55:56 +0000</lastBuildDate> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=3.3.1</generator> <item><title>By: Agostino</title><link>http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/#comment-62605</link> <dc:creator>Agostino</dc:creator> <pubDate>Tue, 20 Sep 2011 16:38:43 +0000</pubDate> <guid
isPermaLink="false">http://www.cyberciti.biz/faq/?p=5476#comment-62605</guid> <description>Not sure, remember that the device is always handled by a CPU. It is useful to set the txqueuelen to small values for slower devices with a high latency (modem links, ISDN) to prevent fast bulk transfers from disturbing interactive traffic. Therefore careful tuning is required to ensure that the sizes of the queues are optimal for your network connection. The default of 100 is inadequate for long distance, high throughput pipes. Also you have to consider the receiver side, we have a similar queue for incoming packets. This queue will build up in size when an interface receives packets faster than the kernel can process them. If this queue is too small (default is 1000), we will begin to loose packets at the receiver, rather than on the network. I have doing more and more testing and personally i have more better performance and lowest cpu load on stress server quad core and giga ethernet at about 4650mi distance from me with this 2 setting:
ifconfig eth0 txqueuelen 2000
echo 2000 &gt; /proc/sys/net/core/netdev_max_backlog
Bye.</description> <content:encoded><![CDATA[<p>Not sure, remember that the device is always handled by a CPU. It is useful to set the txqueuelen to small values for slower devices with a high latency (modem links, ISDN) to prevent fast bulk transfers from disturbing interactive traffic. Therefore careful tuning is required to ensure that the sizes of the queues are optimal for your network connection. The default of 100 is inadequate for long distance, high throughput pipes. Also you have to consider the receiver side, we have a similar queue for incoming packets. This queue will build up in size when an interface receives packets faster than the kernel can process them. If this queue is too small (default is 1000), we will begin to loose packets at the receiver, rather than on the network. I have doing more and more testing and personally i have more better performance and lowest cpu load on stress server quad core and giga ethernet at about 4650mi distance from me with this 2 setting:<br
/> ifconfig eth0 txqueuelen 2000<br
/> echo 2000 &gt; /proc/sys/net/core/netdev_max_backlog<br
/> Bye.</p> ]]></content:encoded> </item> <item><title>By: Maciej</title><link>http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/#comment-62552</link> <dc:creator>Maciej</dc:creator> <pubDate>Mon, 19 Sep 2011 08:38:46 +0000</pubDate> <guid
isPermaLink="false">http://www.cyberciti.biz/faq/?p=5476#comment-62552</guid> <description>I second iwbcman&#039;s comment. Read on the consequences of blindly setting txqueuelen to high values.</description> <content:encoded><![CDATA[<p>I second iwbcman&#8217;s comment. Read on the consequences of blindly setting txqueuelen to high values.</p> ]]></content:encoded> </item> <item><title>By: nima0102</title><link>http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/#comment-62502</link> <dc:creator>nima0102</dc:creator> <pubDate>Sat, 17 Sep 2011 12:11:17 +0000</pubDate> <guid
isPermaLink="false">http://www.cyberciti.biz/faq/?p=5476#comment-62502</guid> <description>Hi
Thanks for your good instruction
May you give me more information about reasons of &quot;PACKET DROP&quot; ?
If NIC gets one corrupted packet, is number increased? or system does not count corrupted packet at all?
Thanks in advance</description> <content:encoded><![CDATA[<p>Hi<br
/> Thanks for your good instruction<br
/> May you give me more information about reasons of &#8220;PACKET DROP&#8221; ?<br
/> If NIC gets one corrupted packet, is number increased? or system does not count corrupted packet at all?</p><p>Thanks in advance</p> ]]></content:encoded> </item> <item><title>By: ddale</title><link>http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/#comment-60907</link> <dc:creator>ddale</dc:creator> <pubDate>Thu, 21 Jul 2011 14:41:32 +0000</pubDate> <guid
isPermaLink="false">http://www.cyberciti.biz/faq/?p=5476#comment-60907</guid> <description>If I want to snmp poll TxQueueLen, what is the number that will be returned - number of packets in the queue? The number of bytes being used by the queue?</description> <content:encoded><![CDATA[<p>If I want to snmp poll TxQueueLen, what is the number that will be returned &#8211; number of packets in the queue? The number of bytes being used by the queue?</p> ]]></content:encoded> </item> <item><title>By: MK2</title><link>http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/#comment-57464</link> <dc:creator>MK2</dc:creator> <pubDate>Thu, 21 Apr 2011 23:15:31 +0000</pubDate> <guid
isPermaLink="false">http://www.cyberciti.biz/faq/?p=5476#comment-57464</guid> <description>I find a slightly cleaner way to make this permanent is to vi /etc/network/interfaces and add the following line below the interface you want to change:
up ifconfig $IFACE txqueuelen 10000
The up allows any following command to be executed when the interface is brought up. This way the line is in the same place as the rest of the interface configuration.</description> <content:encoded><![CDATA[<p>I find a slightly cleaner way to make this permanent is to vi /etc/network/interfaces and add the following line below the interface you want to change:</p><p>up ifconfig $IFACE txqueuelen 10000</p><p>The up allows any following command to be executed when the interface is brought up. This way the line is in the same place as the rest of the interface configuration.</p> ]]></content:encoded> </item> <item><title>By: Maroon</title><link>http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/#comment-54868</link> <dc:creator>Maroon</dc:creator> <pubDate>Thu, 13 Jan 2011 14:01:28 +0000</pubDate> <guid
isPermaLink="false">http://www.cyberciti.biz/faq/?p=5476#comment-54868</guid> <description>Sir,
As for the proxy servers (squid), what is recommended? to increase the tx queue length? or the oposite?
Knowing that we are using server hardware...
Please advise</description> <content:encoded><![CDATA[<p>Sir,</p><p>As for the proxy servers (squid), what is recommended? to increase the tx queue length? or the oposite?</p><p>Knowing that we are using server hardware&#8230;</p><p>Please advise</p> ]]></content:encoded> </item> <item><title>By: iwbcman</title><link>http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/#comment-54798</link> <dc:creator>iwbcman</dc:creator> <pubDate>Mon, 10 Jan 2011 17:09:20 +0000</pubDate> <guid
isPermaLink="false">http://www.cyberciti.biz/faq/?p=5476#comment-54798</guid> <description>Thx for posting this howto for setting txqueuelen.
It should be noted however that increasing the txqueuelen value is a sure fire way to oversaturate your network interface buffers which may cause excessive jitter and DNS resolve timeouts.  The default Linux txqueuelen value of 1000 is already way to high, and reducing this value to some much smaller number will reduce the likelihood of your network interface buffers being oversaturated. Personally I have had good results setting the value to 200.
Basically TCP must be able to have packets dropped quickly in order for the server to know that there is network congestion occurring. The size of the value determines how much buffering takes place(where # of packets translates to number of seconds of data being buffered). When this value is too high the feedback mechanism, which forms the basis for the network congestion avoidance algorithms in TCP, fails, meaning instead of packets being dropped thereby signalling that there is congestion. When the server is unaware of congestion due to excessive buffering the inevitable retransmission of packets only occurs once the problem has gotten too severe- and thus gigantic latencies are introduced, latencies equivalent to the number of seconds buffered according to the value set in txqueuelen.  So the smaller the txqueuelen value, the better are the chances that TCP&#039;s congestion avoidance algorithms can do their job-hence resulting in higher transfer speeds, and the less likely that the buffers will be overfilled leading to gigantic timeouts when retransmission inevitably occurs. Google Jim Gettys and bufferbloat for a better explanation.</description> <content:encoded><![CDATA[<p>Thx for posting this howto for setting txqueuelen.</p><p>It should be noted however that increasing the txqueuelen value is a sure fire way to oversaturate your network interface buffers which may cause excessive jitter and DNS resolve timeouts.  The default Linux txqueuelen value of 1000 is already way to high, and reducing this value to some much smaller number will reduce the likelihood of your network interface buffers being oversaturated. Personally I have had good results setting the value to 200.</p><p>Basically TCP must be able to have packets dropped quickly in order for the server to know that there is network congestion occurring. The size of the value determines how much buffering takes place(where # of packets translates to number of seconds of data being buffered). When this value is too high the feedback mechanism, which forms the basis for the network congestion avoidance algorithms in TCP, fails, meaning instead of packets being dropped thereby signalling that there is congestion. When the server is unaware of congestion due to excessive buffering the inevitable retransmission of packets only occurs once the problem has gotten too severe- and thus gigantic latencies are introduced, latencies equivalent to the number of seconds buffered according to the value set in txqueuelen.  So the smaller the txqueuelen value, the better are the chances that TCP&#8217;s congestion avoidance algorithms can do their job-hence resulting in higher transfer speeds, and the less likely that the buffers will be overfilled leading to gigantic timeouts when retransmission inevitably occurs. Google Jim Gettys and bufferbloat for a better explanation.</p> ]]></content:encoded> </item> <item><title>By: Yevgen</title><link>http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/#comment-44189</link> <dc:creator>Yevgen</dc:creator> <pubDate>Thu, 22 Oct 2009 09:56:40 +0000</pubDate> <guid
isPermaLink="false">http://www.cyberciti.biz/faq/?p=5476#comment-44189</guid> <description>You can use also this command:
ip link set eth1 txqueuelen 10000</description> <content:encoded><![CDATA[<p>You can use also this command:<br
/> ip link set eth1 txqueuelen 10000</p> ]]></content:encoded> </item> </channel> </rss>
