Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Mar 2009 01:15:11 +1100 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Luigi Rizzo <rizzo@iet.unipi.it>
Cc:        freebsd-ipfw@freebsd.org, Sebastian Mellmann <sebastian.mellmann@net.t-labs.tu-berlin.de>
Subject:   Re: ipfw (dummynet) adds delay, but not configured to do so
Message-ID:  <20090307003515.W71460@sola.nimnet.asn.au>
In-Reply-To: <20090306070011.GA94585@onelab2.iet.unipi.it>
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>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Fri, 6 Mar 2009, Luigi Rizzo wrote:
 > On Fri, Mar 06, 2009 at 04:23:29PM +1100, Ian Smith wrote:
 > ...
 > > ipfw(8) at 7.1-RELEASE:
 > > 
 > > delay ms-delay
 > > 	Propagation delay, measured in milliseconds.  The value is
 > > 	rounded to the next multiple of the clock tick (typically 10ms,
 > > 	but it is a good practice to run kernels with ``options HZ=1000''
 > > 	to reduce the granularity to 1ms or less).  Default value is 0,
 > > 	meaning no delay.
 > > 
 > > Firstly, this is well out of date; the default has been HZ=1000 since 
 > > 6.1-R or earlier, a ten-fold increase on the old 100Hz.  I'm not sure 
 > > however that 10000 would be a suitable suggestion, even with today's 
 > > processor speeds?
 > 
 > You can bump it up HZ but there are things that do not scale as well
 > as CPU clock frequencies. E.g. the access to slow peripherals on
 > the PCI or ISA buses is still as slow as it was 15 years ago,
 > and if your timer-driven routine needs to access one of those
 > peripherals it might consume a significant number of microseconds.
 > At HZ=1000 this is probably negligible; at HZ=10k you might start
 > noticing.

Indeed.  HZ=1000 is a bit busy (like ~+10% CPU) on a Celeron 300 laptop, 
now at 250Hz, no dummynet.  I expect 10kHz slicing would drown it, ie 
without some qualification re CPU clock, suggested defaults are risky.

 > > 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.

Think I've almost starting to get this, thanks.

cheers, Ian



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20090307003515.W71460>