os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

The net.inet.tcp.inflight* sysctls are in their own, separate sysctl

Browse source 
node since revision 1.196 of `src/sys/netinet/tcp_subr.c'.  Update
their description in the Handbook, but keep a reference to the old
pre-5.3-RELEASE names until we stop supporting 4.X releases (a couple
of years from now).

PR:		docs/76462
Submitted by:	Joel Dahl <joel@automatvapen.se>
This commit is contained in:
Giorgos Keramidas 2005-01-20 12:36:00 +00:00
parent eda73f8915
commit 1c87db4bc5
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=23596
1 changed files with 18 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

24
en_US.ISO8859-1/books/handbook/config/chapter.sgml
View file

@ -2171,12 +2171,12 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
<indexterm> <indexterm>
<primary>TCP Bandwidth Delay Product Limiting</primary> <primary>TCP Bandwidth Delay Product Limiting</primary>
<secondary><varname>net.inet.tcp.inflight_enable</varname></secondary> <secondary><varname>net.inet.tcp.inflight.enable</varname></secondary>
</indexterm> </indexterm>
<para>The TCP Bandwidth Delay Product Limiting is similar to <para>The TCP Bandwidth Delay Product Limiting is similar to
TCP/Vegas in NetBSD. It can be TCP/Vegas in NetBSD. It can be
enabled by setting <varname>net.inet.tcp.inflight_enable</varname> enabled by setting <varname>net.inet.tcp.inflight.enable</varname>
sysctl variable to <literal>1</literal>. The system will attempt sysctl variable to <literal>1</literal>. The system will attempt
to calculate the bandwidth delay product for each connection and to calculate the bandwidth delay product for each connection and
limit the amount of data queued to the network to just the amount limit the amount of data queued to the network to just the amount
@ -2187,9 +2187,9 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
with a high bandwidth delay product), especially if you are also with a high bandwidth delay product), especially if you are also
using window scaling or have configured a large send window. If using window scaling or have configured a large send window. If
you enable this option, you should also be sure to set you enable this option, you should also be sure to set
<varname>net.inet.tcp.inflight_debug</varname> to <varname>net.inet.tcp.inflight.debug</varname> to
<literal>0</literal> (disable debugging), and for production use <literal>0</literal> (disable debugging), and for production use
setting <varname>net.inet.tcp.inflight_min</varname> to at least setting <varname>net.inet.tcp.inflight.min</varname> to at least
<literal>6144</literal> may be beneficial. However, note that <literal>6144</literal> may be beneficial. However, note that
setting high minimums may effectively disable bandwidth limiting setting high minimums may effectively disable bandwidth limiting
depending on the link. The limiting feature reduces the amount of depending on the link. The limiting feature reduces the amount of
@ -2202,7 +2202,7 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
/ server side). It has no effect on data reception (downloading). / server side). It has no effect on data reception (downloading).
</para> </para>
<para>Adjusting <varname>net.inet.tcp.inflight_stab</varname> is <para>Adjusting <varname>net.inet.tcp.inflight.stab</varname> is
<emphasis>not</emphasis> recommended. This parameter defaults to <emphasis>not</emphasis> recommended. This parameter defaults to
20, representing 2 maximal packets added to the bandwidth delay 20, representing 2 maximal packets added to the bandwidth delay
product window calculation. The additional window is required to product window calculation. The additional window is required to
@ -2211,9 +2211,21 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
links (though still much lower than you would get without the links (though still much lower than you would get without the
inflight algorithm). In such cases, you may wish to try reducing inflight algorithm). In such cases, you may wish to try reducing
this parameter to 15, 10, or 5; and may also have to reduce this parameter to 15, 10, or 5; and may also have to reduce
<varname>net.inet.tcp.inflight_min</varname> (for example, to <varname>net.inet.tcp.inflight.min</varname> (for example, to
3500) to get the desired effect. Reducing these parameters 3500) to get the desired effect. Reducing these parameters
should be done as a last resort only.</para> should be done as a last resort only.</para>
<note>
<para>In 4.X and earlier releases of &os; the
<literal>inflight</literal> sysctl variables are directly under
<varname>net.inet.tcp</varname>. Their names are
(in alphabetic order):
<varname>net.inet.tcp.inflight.debug</varname>,
<varname>net.inet.tcp.inflight.enable</varname>,
<varname>net.inet.tcp.inflight.max</varname>,
<varname>net.inet.tcp.inflight.min</varname>,
<varname>net.inet.tcp.inflight.stab</varname>.</para>
</note>
</sect3> </sect3>
</sect2> </sect2>
</sect1> </sect1>