Date: Fri, 6 Mar 2009 08:22:29 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Sebastian Mellmann <sebastian.mellmann@net.t-labs.tu-berlin.de> Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw (dummynet) adds delay, but not configured to do so Message-ID: <20090306072229.GB94585@onelab2.iet.unipi.it> In-Reply-To: <64393.62.206.221.107.1236323210.squirrel@anubis.getmyip.com> References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090304210017.GA29615@onelab2.iet.unipi.it> <20090306153751.D71460@sola.nimnet.asn.au> <20090306070011.GA94585@onelab2.iet.unipi.it> <64393.62.206.221.107.1236323210.squirrel@anubis.getmyip.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 06, 2009 at 08:06:50AM +0100, Sebastian Mellmann wrote: > > >> Secondly, apropos Sebastian's experience, should this say "The value > >> (even if 0) is rounded to the next multiple of the clock tick .." ? > >> ^^^^^^^^^^^ > > > > 0 is rounded to 0 so that's not an issue. > > The delay Sebastian is seeing comes from the babdnwidth limitation, > > which is causing a non-zero "transmission time" which is rounded up. > > Let me get this right: > > When I configure a pipe with bandwidth limitations, I'll always get some > additional delay when a packet passes this pipe? "additional" compared to the case of no bandwidth limitations. But the delay is exactly the effect of bandwidth limitations and the presence of the queue (and possibly +/- 1 tick of rounding), so you have to understand what is modeled if you want to account for it precisely.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090306072229.GB94585>