Date: Thu, 16 Sep 2010 22:11:55 +0000 (UTC) From: Andre Oppermann <andre@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r212769 - head/share/man/man4 Message-ID: <201009162211.o8GMBtnI008623@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: andre Date: Thu Sep 16 22:11:55 2010 New Revision: 212769 URL: http://svn.freebsd.org/changeset/base/212769 Log: The inflight bandwidth limiter was removed in r212765. Modified: head/share/man/man4/tcp.4 Modified: head/share/man/man4/tcp.4 ============================================================================== --- head/share/man/man4/tcp.4 Thu Sep 16 21:18:25 2010 (r212768) +++ head/share/man/man4/tcp.4 Thu Sep 16 22:11:55 2010 (r212769) @@ -32,7 +32,7 @@ .\" From: @(#)tcp.4 8.1 (Berkeley) 6/5/93 .\" $FreeBSD$ .\" -.Dd August 16, 2008 +.Dd September 16, 2010 .Dt TCP 4 .Os .Sh NAME @@ -383,72 +383,6 @@ code. For this reason, we use 200ms of slop and a near-0 minimum, which gives us an effective minimum of 200ms (similar to .Tn Linux ) . -.It Va inflight.enable -Enable -.Tn TCP -bandwidth-delay product limiting. -An attempt will be made to calculate -the bandwidth-delay product for each individual -.Tn TCP -connection, and limit -the amount of inflight data being transmitted, to avoid building up -unnecessary packets in the network. -This option is recommended if you -are serving a lot of data over connections with high bandwidth-delay -products, such as modems, GigE links, and fast long-haul WANs, and/or -you have configured your machine to accommodate large -.Tn TCP -windows. -In such -situations, without this option, you may experience high interactive -latencies or packet loss due to the overloading of intermediate routers -and switches. -Note that bandwidth-delay product limiting only effects -the transmit side of a -.Tn TCP -connection. -.It Va inflight.debug -Enable debugging for the bandwidth-delay product algorithm. -.It Va inflight.min -This puts a lower bound on the bandwidth-delay product window, in bytes. -A value of 1024 is typically used for debugging. -6000-16000 is more typical in a production installation. -Setting this value too low may result in -slow ramp-up times for bursty connections. -Setting this value too high effectively disables the algorithm. -.It Va inflight.max -This puts an upper bound on the bandwidth-delay product window, in bytes. -This value should not generally be modified, but may be used to set a -global per-connection limit on queued data, potentially allowing you to -intentionally set a less than optimum limit, to smooth data flow over a -network while still being able to specify huge internal -.Tn TCP -buffers. -.It Va inflight.stab -The bandwidth-delay product algorithm requires a slightly larger window -than it otherwise calculates for stability. -This parameter determines the extra window in maximal packets / 10. -The default value of 20 represents 2 maximal packets. -Reducing this value is not recommended, but you may -come across a situation with very slow links where the -.Xr ping 8 -time -reduction of the default inflight code is not sufficient. -If this case occurs, you should first try reducing -.Va inflight.min -and, if that does not -work, reduce both -.Va inflight.min -and -.Va inflight.stab , -trying values of -15, 10, or 5 for the latter. -Never use a value less than 5. -Reducing -.Va inflight.stab -can lead to upwards of a 20% underutilization of the link -as well as reducing the algorithm's ability to adapt to changing -situations and should only be done as a last resort. .It Va rfc3042 Enable the Limited Transmit algorithm as described in RFC 3042. It helps avoid timeouts on lossy links and also when the congestion window
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009162211.o8GMBtnI008623>