ipfw (dummynet) adds delay, but not configured to do so

[Ian Smith]

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