From joel@automatvapen.se  Wed Jan 19 12:40:33 2005
Return-Path: <joel@automatvapen.se>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 9DF1416A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 19 Jan 2005 12:40:33 +0000 (GMT)
Received: from av9-2-sn2.hy.skanova.net (av9-2-sn2.hy.skanova.net [81.228.8.180])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 89C3743D58
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 19 Jan 2005 12:40:32 +0000 (GMT)
	(envelope-from joel@automatvapen.se)
Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502)
	id 5A84D37F5F; Wed, 19 Jan 2005 13:40:31 +0100 (CET)
Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93])
	by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 47ABD37E5D
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 19 Jan 2005 13:40:31 +0100 (CET)
Received: from dude.automatvapen.se (t10o55p32.telia.com [81.225.221.152])
	by smtp4-2-sn2.hy.skanova.net (Postfix) with SMTP id 0AF0937E42
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 19 Jan 2005 13:40:29 +0100 (CET)
Received: by dude.automatvapen.se (sSMTP sendmail emulation); Wed, 19 Jan 2005 13:40:39 +0100
Message-Id: <20050119124029.0AF0937E42@smtp4-2-sn2.hy.skanova.net>
Date: Wed, 19 Jan 2005 13:40:39 +0100
From: "Joel Dahl" <joel@automatvapen.se>
Reply-To: Joel Dahl <joel@automatvapen.se>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [patch] Handbook, net.inet.tcp.inflight_* -> net.inet.tcp.inflight.*
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         76462
>Category:       docs
>Synopsis:       [patch] Handbook, net.inet.tcp.inflight_* -> net.inet.tcp.inflight.*
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    keramida
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 19 12:50:29 GMT 2005
>Closed-Date:    Thu Jan 20 12:37:00 GMT 2005
>Last-Modified:  Thu Jan 20 12:37:00 GMT 2005
>Originator:     Joel Dahl
>Release:        FreeBSD 5.3-STABLE i386
>Organization:
>Environment:
System: FreeBSD dude.automatvapen.se 5.3-STABLE FreeBSD 5.3-STABLE #0: Sat Jan 1 14:36:28 CET 2005 joel@dude.automatvapen.se:/usr/obj/usr/src/sys/WRK i386

	
>Description:
$ sysctl net.inet.tcp.inflight
net.inet.tcp.inflight.enable: 1
net.inet.tcp.inflight.debug: 0
net.inet.tcp.inflight.min: 6144
net.inet.tcp.inflight.max: 1073725440
net.inet.tcp.inflight.stab: 20

	
>How-To-Repeat:
	
>Fix:
	

--- dot.diff begins here ---
Index: chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml,v
retrieving revision 1.198
diff -u -r1.198 chapter.sgml
--- chapter.sgml	14 Jan 2005 12:51:52 -0000	1.198
+++ chapter.sgml	19 Jan 2005 12:26:37 -0000
@@ -2171,12 +2171,12 @@
 
 	<indexterm>
 	  <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>
 
 	<para>The TCP Bandwidth Delay Product Limiting is similar to
 	  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
 	  to calculate the bandwidth delay product for each connection and
 	  limit the amount of data queued to the network to just the amount
@@ -2187,9 +2187,9 @@
 	  with a high bandwidth delay product), especially if you are also
 	  using window scaling or have configured a large send window.  If
 	  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
-	  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
 	  setting high minimums may effectively disable bandwidth limiting
 	  depending on the link.  The limiting feature reduces the amount of
@@ -2202,7 +2202,7 @@
 	  / server side).  It has no effect on data reception (downloading).
 	</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
 	  20, representing 2 maximal packets added to the bandwidth delay
 	  product window calculation.  The additional window is required to
@@ -2211,7 +2211,7 @@
 	  links (though still much lower than you would get without the
 	  inflight algorithm).  In such cases, you may wish to try reducing
 	  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
 	  should be done as a last resort only.</para>
       </sect3>
--- dot.diff ends here ---


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-doc->keramida 
Responsible-Changed-By: keramida 
Responsible-Changed-When: Thu Jan 20 10:04:53 GMT 2005 
Responsible-Changed-Why:  
I will work with Joel on this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=76462 
State-Changed-From-To: open->closed 
State-Changed-By: keramida 
State-Changed-When: Thu Jan 20 12:36:05 GMT 2005 
State-Changed-Why:  
Committed.  Thanks :) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=76462 
>Unformatted:
