Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Mar 2009 08:00:11 +0100
From:      Luigi Rizzo <>
To:        Ian Smith <>
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 Fri, Mar 06, 2009 at 04:23:29PM +1100, Ian Smith wrote:
> 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?

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

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


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