Date: Sun, 26 Feb 2006 10:48:51 -0600 From: "Donald J. O'Neill" <duncan.fbsd@gmail.com> To: freebsd-questions@freebsd.org Cc: ptitoliv <ptitoliv@frenchsuballiance.cjb.net> Subject: Re: Bandwidth Problems with Freebsd 5.x Message-ID: <200602261048.52172.duncan.fbsd@gmail.com> In-Reply-To: <4401B6D0.6000404@frenchsuballiance.cjb.net> References: <43F73267.6010807@frenchsuballiance.cjb.net> <7.0.1.0.2.20060218070451.041f81b0@antimatter.net> <4401B6D0.6000404@frenchsuballiance.cjb.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 26 February 2006 08:10, ptitoliv wrote:
> Hello Everybody,
>
> I made lots of searches on the Internet and I found something about
> the option
>
> net.inet.tcp.inflight.enable.
>
> If I set this value to 0, my bandwitdh problems are resolved.
>
> Does anybody knows something about this options and why can it be the
> origin of this problem ?
>
> Regards,
> Ptitoliv
> _______________________________________________
I made some quick check, there is some information available. Most of it
seems to be pretty recent. I suggest joining freebsd-stable@ as there
is some questions going on about it there.
You can also google for information on:
net.inet.tcp.inflight.enable
There may be other things to look at and good reasons to have it
enabled, or disabled.
Take from chapter 11 of the handbook:
=====================
11.13.2.2 TCP Bandwidth Delay Product
The TCP Bandwidth Delay Product Limiting is similar to TCP/Vegas in
NetBSD. It can be enabled by setting net.inet.tcp.inflight.enable
sysctl variable to 1. 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, Gigabit
Ethernet, or even 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 net.inet.tcp.inflight.debug to 0
(disable debugging), and for production use setting
net.inet.tcp.inflight.min to at least 6144 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 data built up in intermediate route 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 has no effect on data
reception (downloading).
Adjusting net.inet.tcp.inflight.stab is not recommended. This parameter
defaults to 20, representing 2 maximal packets added to the bandwidth
delay product window calculation. The additional window is required to
stabilize the algorithm and improve responsiveness to changing
conditions, but it can also result in higher ping times over slow 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 net.inet.tcp.inflight.min
(for example, to 3500) to get the desired effect. Reducing these
parameters should be done as a last resort only.
Note: In 4.X and earlier releases of FreeBSD the inflight sysctl
variables are directly under net.inet.tcp. Their names were (in
alphabetic order): net.inet.tcp.inflight_debug,
net.inet.tcp.inflight_enable, net.inet.tcp.inflight_max,
net.inet.tcp.inflight_min, net.inet.tcp.inflight_stab.
Don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200602261048.52172.duncan.fbsd>