From cec04a19093459bef55fb2c53af54f99dac9b333 Mon Sep 17 00:00:00 2001 From: dillon Date: Sat, 17 Aug 2002 20:44:24 +0000 Subject: Oops, last manual commit was to -stable, should have been to -current. No biggy, the code MFC to stable will catch up to the docs in a week. X-MFC after: -7 days --- share/man/man4/tcp.4 | 30 ++++++++++++++++++++++++++++++ share/man/man7/tuning.7 | 23 +++++++++++++++++++++++ 2 files changed, 53 insertions(+) (limited to 'share') diff --git a/share/man/man4/tcp.4 b/share/man/man4/tcp.4 index 923aa39..c8a942f 100644 --- a/share/man/man4/tcp.4 +++ b/share/man/man4/tcp.4 @@ -300,6 +300,36 @@ no reseeding will occur. Reseeding should not be necessary, and will break .Dv TIME_WAIT recycling for a few minutes. +.It tcp.inflight_enable +Enable +.Tn TCP +bandwidth delay product limiting. An attempt will be made to calculate +the bandwidth delay product for each individual 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 accomodate large 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 TCP connection. +.It tcp.inflight_debug +Enable debugging for the bandwidth delay product algorithm. This may +default to on (1) so if you enable the algorithm you should probably also +disable debugging by setting this variable to 0. +.It tcp.inflight_min +This puts an 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 tcp.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 then optimum limit to smooth data flow over a +network while still being able to specify huge internal TCP buffers. .El .Sh ERRORS A socket operation may fail with one of the following errors returned: diff --git a/share/man/man7/tuning.7 b/share/man/man7/tuning.7 index daa93d3..4a18e25 100644 --- a/share/man/man7/tuning.7 +++ b/share/man/man7/tuning.7 @@ -522,6 +522,29 @@ In such environments, setting the sysctl to 0 may reduce the occurrence of TCP session disconnections. .Pp The +.Va net.inet.tcp.inflight_enable +sysctl turns on bandwidth delay product limiting for all TCP connections. +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 required to maintain optimum throughput. This feature is useful +if you are serving data over modems, GigE, or high speed WAN links (or +any other link 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 +.Va net.inet.tcp.inflight_debug +to 0 (disable debugging), and for production use setting +.Va net.inet.tcp.inflight_min +to at least 6144 may be beneficial. Note, however, that setting high +minimums may effectively disable bandwidth limiting depending on the link. +The limiting feature reduces the amount of data built up in intermediate +router and switch packet queues as well as reduces the amount of data built +up in the local host's interface queue. With fewer packets queued up, +interactive connections, especially over slow modems, will also be able +to operate with lower round trip times. However, note that this feature +only effects data transmission (uploading / server-side). It does not +effect data reception (downloading). +.Pp +The .Va kern.ipc.somaxconn sysctl limits the size of the listen queue for accepting new TCP connections. The default value of 128 is typically too low for robust handling of new -- cgit v1.1