From owner-freebsd-ipfw@FreeBSD.ORG Sat May 31 03:12:48 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8672F4C9 for ; Sat, 31 May 2014 03:12:48 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 506F82B4B for ; Sat, 31 May 2014 03:12:47 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s4V3CfiQ072620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 May 2014 20:12:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <538948A5.2050003@freebsd.org> Date: Sat, 31 May 2014 11:12:37 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: bycn82 , "'Luigi Rizzo'" , freebsd-ipfw@FreeBSD.org Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw References: <201405291520.s4TFK124032925@freefall.freebsd.org> <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> <53889829.6030307@freebsd.org> <000001cf7c18$c6cbd460$54637d20$@gmail.com> In-Reply-To: <000001cf7c18$c6cbd460$54637d20$@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 03:12:48 -0000 On 5/30/14, 11:06 PM, bycn82 wrote: > Hi , > I am currently using HZ=2 in my testing environment, then the traffic in dummynet by default delays for 500ms, the same reason for this PPS. Because it is based on the TICK. > > How about introduce another option named PPT ? ( sounds familiar! ). and in the ipfw_chk, PPS can just convert the duration from measurement `milliseconds` to `ticks`, and can reuse the logic of PPT. PPT technically is perfect. But for user, It is ugly. They need to know what TICK is ! anyway, at least user have an option to choose when they really need to be accurate. the user parameter needs to be pps.. you need to convert in internally to a fixedpoint representation of PPT. > > Regards, > Bycn82 > >> -----Original Message----- >> From: Julian Elischer [mailto:julian@freebsd.org] >> Sent: 30 May, 2014 22:40 >> To: bycn82; 'Luigi Rizzo'; freebsd-ipfw@FreeBSD.org >> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >> >> On 5/29/14, 11:30 PM, bycn82 wrote: >>> I got it, >>> >>> if the HZ=3, it always cannot meet the " 1 packet per 500ms" perfectly. >>> But if we to "X packet per Y ticks", actually the result is the same, still >> cannot meet the "1 packet per 500 ms" perfectly, instead, the "packet per Y >> ticks" will force user to use " X packet per Y*300 ms". And the user need to >> understand how many millisecond each tick is . >> on e can write an implementation that notes how much the calculation was >> off by for each tick and corrects the number for the next tick.. >> >> e.g. with Hz=10, 8pps should give sometimes 1ppt and sometimes 0ppt >> but a simple calculation will always give 0 every tick so you need to have >> some way of carrying forward 'unused bandwidth' so that teh calculation >> looks like (over a second) >> ppt(real) ppt(int) >> 0.8 (0) >> 0.8+0.8=1.6 (1) >> 0.6+0.8=1.4 (1) (subtract 1 from 1.6, and then add the 0.8 per tick) >> 0.4+0.8=1.2 (1) >> 0.2+0.8=1.0 (1) >> 0.0+0.8=0.8(0) >> (sequence repeats) >> 0.8+0.8=1.6 (1) >> 0.6+0.8=1.4 (1) >> 0.4+0.8=1.2 (1) >> 0.2+0.8=1.0 (1) >> 0.0+0.8=0.8(0) >> >> if you use any of the the int(ppt) in a tick you subtract the amount used. if >> not you allow it to build, up to some maximum value. >> >> (sequence repeats) >> 0.8+0.8=1.6 (1) (not used) >> 1.6+0.8=2.4 (2) (not used) >> 2.4+0.8=3.2 (3) (not used) >> 3.2+0.8=4.0 (4) (4 packets allowed through further packets held or >> dropped) >> 0.0+0.8=0.8(0) >> 0.8+0.8=1.6 (1) (not used) >> 1.6+0.8=2.4 (2) (not used) >> 2.4+0.8=3.2 (3) 1 packet used.. 1.0 subtracted >> 2.2+0.8=3.0 (4) (4 packets allowed through further packets held or >> dropped) >> 0.0+0.8=0.8(0) >> etc. >> >> one does this with some form of fixed point arithmetic as floating point isn't >> used in the kernel. >> >> >> >>> So I will update it this weekend. >>> >>> >>>> -----Original Message----- >>>> From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd- >>>> ipfw@freebsd.org] On Behalf Of 'Luigi Rizzo' >>>> Sent: 29 May, 2014 23:20 >>>> To: freebsd-ipfw@FreeBSD.org >>>> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >>>> >>>> The following reply was made to PR kern/189720; it has been noted by >>>> GNATS. >>>> >>>> From: 'Luigi Rizzo' >>>> To: bycn82 >>>> Cc: bug-followup@FreeBSD.org >>>> Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw >>>> Date: Thu, 29 May 2014 17:17:59 +0200 >>>> >>>> On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote: >>>> > >>>> > >>>> > -----Original Message----- >>>> > From: Luigi Rizzo [mailto:rizzo@iet.unipi.it] > Sent: 29 May, 2014 22:12 > >> To: >>>> bug-followup@FreeBSD.org; bycn82@gmail.com > Subject: kern/189720: >>>> [ipfw] [patch] pps action for ipfw > > Hi, > I have looked at the update >> from >>>> May 13th but it is not ready yet, the code assumes HZ=1000 so 1 tick=1ms. >>>> > >>>> > The translation can be done in userspace or in the kernel. >>>> > I would prefer the latter. >>>> > I see, >>>> > If the HZ=3, that means every tick=333ms > And if the user wants to ??? >> 1 >>>> packet per 500ms???, then in the backend will not do the exactly the >> same as >>>> what user expect. >>>> > >>>> > Actually the implementation should be ???packets per ticks???, so how >>>> about this? Instead of translate it in codes. Why not update the document, >>>> and explain it to the user in the document ? >>>> >>>> 'Packets per tick' this is not a useful specification since the tick's duration >> is >>>> unknown to the user. >>>> Depending on the platform you can have HZ ranging from 15-20 (on >> windows) >>>> to 10000 or even more. Normal values are 100, 250, 1000 but you just >> cannot >>>> know what you are going to get. >>>> >>>> Yes there are rounding issues, and yes it is boring to write code to >> handle >>>> them. >>>> >>>> luigi >>>> _______________________________________________ >>>> freebsd-ipfw@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>>> To unsubscribe, send any mail to "freebsd-ipfw- >> unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-ipfw@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >>> > >