From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 6 06:55:09 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06CA51065678 for ; Fri, 6 Mar 2009 06:55:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id BEA4A8FC14 for ; Fri, 6 Mar 2009 06:55:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 64D9A730A1; Fri, 6 Mar 2009 08:00:11 +0100 (CET) Date: Fri, 6 Mar 2009 08:00:11 +0100 From: Luigi Rizzo To: Ian Smith Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090306153751.D71460@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org, Sebastian Mellmann Subject: Re: ipfw (dummynet) adds delay, but not configured to do so X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 06:55:09 -0000 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 noticing. > 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. cheers luigi