The inflight bandwidth limiter was removed in r212765.
This commit is contained in:
parent
1c18314d17
commit
d8b03e05a9
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=212769
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user