Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Mar 2009 16:23:29 +1100 (EST)
From:      Ian Smith <>
To:        Luigi Rizzo <>
Cc:, Sebastian Mellmann <>
Subject:   Re: ipfw (dummynet) adds delay, but not configured to do so
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Wed, 4 Mar 2009, Luigi Rizzo wrote:
 > On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote:
 > > Hi everyone!
 > > 
 > > I hope this is the right place to ask.
 > > 
 > > I've got a IPFW ruleset that looks like this:
 > > 
 > > cmd=ipfw
 > > bottleneck_bandwidth=100Mbit/s
 > > in_if="em0"
 > > 
 > > $cmd pipe 500 config bw $bottleneck_bandwidth
 > > $cmd add pipe 500 all from any to any via $in_if
 > the delay that a packet experiences corresponds to len/bandwidth,
 > often rounded up to the next clock tick (1ms is the default).
 > You get one delay inbound, one delay outbound, so that's 2ms.

After finally getting almost enough sleep, I've just realised, duh, that 
Sebastian likely already had the default kern.hz=1000, ie 1ms, so would 
need something faster to achieve less delay.

Which led me to take my own medicine and reread the dummynet sections in 
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?

Secondly, apropos Sebastian's experience, should this say "The value
(even if 0) is rounded to the next multiple of the clock tick .." ?

cheers, Ian

Want to link to this message? Use this URL: <>