Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Jul 2001 10:08:57 -0700 (PDT)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        Leo Bicknell <bicknell@ufp.org>
Cc:        Drew Eckhardt <drew@PoohSticks.ORG>, Leo Bicknell <bicknell@ufp.org>, hackers@FreeBSD.ORG
Subject:   Re: Network performance tuning.
Message-ID:  <200107131708.f6DH8ve65071@earth.backplane.com>
References:  <200107130128.f6D1SFE59148@earth.backplane.com> <200107130217.f6D2HET67695@revolt.poohsticks.org> <20010712223042.A77503@ussenterprise.ufp.org>

next in thread | previous in thread | raw e-mail | index | archive | help
    Ok, I'm about half way through writing up a patch set to implement
    the bandwidth delay product write-buffer calculation.  It may still be a
    few days before it is presentable.  The TCP stack already has almost
    everything required to do the calculation.  Adding a fair-share piece in
    addition to the bwdelay product will also be fairly easy, at least for
    the write-side.

    The basic problem with calculating the bandwidth delay product is that
    it is an inherently unstable calculation.  It has to be a continuous,
    slow moving calculation or you have a good chance of destabilizing the
    network (think about having a thousand connections all trying to figure
    out each of their bandwidth delay productions for traffic sharing random
    hops in the network).  The advantage of being able to do it successfully,
    however, is huge.  Rather then allowing the TCP connection to start to 
    lose packets before backing off, the bandwidth delay product calculation
    instead focuses on not overloading the network in the first place while
    still maintaining optimum performance.

    I took a look at the paper Leo pointed out to me:

	http://www.psc.edu/networking/auto.html

    It's a very interesting paper, and the graphs do in fact show the type
    of instability that can occur.  The code is a mess, though.  I think it
    is possible to generate a much less noisy patch set by taking a higher
    level approach to solving the problem.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107131708.f6DH8ve65071>