Re: net.inet.tcp.inflight_enable

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I made another experiences and found that, if HZ is increased, the
:throughput is improved.  Note that bandwidth=100Mbit/s=12.5Mbyte/s
:and RTT=20ms in my experimental environment.  Here are results of
:time to send 512KB data without losses.

    Yes, I would expect this, but I am not going to go the same route 
    that FreeBSD has gone where a high HZ is required for the system to
    operate smoothly.

    The bandwidth estimation works with any HZ value, but it takes a lot
    longer to get a good estimate when HZ is low simply because the 
    granularity of the measurement is far higher.  But, again, this 
    particular case is only testing short transfers.  I believe this issue
    can be solved with initial conditions.  Probably not with the patch
    I enclosed earlier (it's too unstable at the beginning of a transfer).
    Probably with something stored in the route table.

:As a result, if one uses BDP limiting, I think 1/HZ should be set to
:much smaller value than RTT.
:...
:Regards,
:Noritoshi Demizu
:

    No, we definitely are not going to do this.  First, it's impossible
    to scale the value to the network because, frankly, the network can
    be anything from a PPP connection over a serial port to a 10GigE
    link.  Secondly, it's a bad idea to make subsystems dependant on
    the system's base tick being 'fast'. 

    We could tune the system to make BDP work perfectly in your test
    environment, but it would skew the parameters too much relative to
    other things the system does.  e.g. the scheduler would become much
    less efficient, and system overheads would increase (significantly at
    10,000 hz which would only be 100uS per interrupt).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>