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. So I will update it this weekend. -Original Message- From: owner-freebsd-i...@freebsd.org [mailto:owner-freebsd- i...@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-follo...@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:ri...@iet.unipi.it] > Sent: 29 May, 2014 22:12 > To: bug-follo...@freebsd.org; byc...@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 1 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-unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
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-i...@freebsd.org [mailto:owner-freebsd- i...@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-follo...@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:ri...@iet.unipi.it] > Sent: 29 May, 2014 22:12 > To: bug-follo...@freebsd.org; byc...@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 1 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-unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
RE: kern/189720: [ipfw] [patch] pps action for ipfw
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. Regards, Bycn82 > -Original Message- > From: Julian Elischer [mailto:jul...@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-i...@freebsd.org [mailto:owner-freebsd- > >> i...@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-follo...@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:ri...@iet.unipi.it] > Sent: 29 May, 2014 > >> 22:12 > > To: > >> bug-follo...@freebsd.org; byc...@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 1 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- > unsubscr...@freebsd.org" > > ___ > > freebsd-ipfw@freebsd.org mailing list >
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: "bycn82" To: , Cc: "Luigi Rizzo" Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw Date: Sat, 31 May 2014 00:53:56 +0800 This is a multipart message in MIME format. --=_NextPart_000_0002_01CF7C6A.CF4B9B50 Content-Type: multipart/alternative; boundary="=_NextPart_001_0003_01CF7C6A.CF4B9B50" --=_NextPart_001_0003_01CF7C6A.CF4B9B50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 1. Add static int to store the value of kern.hz 2. Convert the duration into number of ticks based on kern.hz regards, bycn82 --=_NextPart_001_0003_01CF7C6A.CF4B9B50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable http://schemas.microsoft.com/office/2004/12/omml"; = xmlns=3D"http://www.w3.org/TR/REC-html40";>1. Add = static int to store the value of kern.hz2. = Convert the duration into number of ticks based = on =C2=A0kern.hz regards,bycn82 --=_NextPart_001_0003_01CF7C6A.CF4B9B50-- --=_NextPart_000_0002_01CF7C6A.CF4B9B50 Content-Type: application/octet-stream; name="pps.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pps.patch" Index: sbin/ipfw/ipfw.8=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sbin/ipfw/ipfw.8 (revision 266886)=0A= +++ sbin/ipfw/ipfw.8 (working copy)=0A= @@ -602,6 +602,14 @@=0A= Note: logging is done after all other packet matching conditions=0A= have been successfully verified, and before performing the
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-follo...@freebsd.org Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw Date: Fri, 30 May 2014 19:16:10 +0200 On Sat, May 31, 2014 at 12:53:56AM +0800, bycn82 wrote: > 1. Add static int to store the value of kern.hz this is unnecessary. There is already a global variable called "hz" which contains the correct information > 2. Convert the duration into number of ticks based on kern.hz this is done incorrectly. First, hz does not change at runtime so it is unnecessary to recompute the duration on every instace, even more since this is costing you one division. You should adjust the value when the rule is injected in the kernel, perhaps adding a couple of fields in the rule so you can store the adjusted duration and threshold (see below). Second, you are still not doing the rounding correctly. When the requested interval is shorter than a tick, you adjust the interval but leave the limit unchanged, which means you are reducing the limit below what the user wants. Instead you should correct the limit so that it approximates the desired rate; one above or one below is not a problem, but your code might be off by a very large factor. BTW even in the other case you are always adding 1 tick unconditionally. A correct way to do the rounding is (pps->duration * hz + 999)/1000 (and then again adjust the count according to the actual duration) cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: kern/189720: [ipfw] [patch] pps action for ipfw
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:jul...@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-i...@freebsd.org [mailto:owner-freebsd- i...@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-follo...@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:ri...@iet.unipi.it] > Sent: 29 May, 2014 22:12 > To: bug-follo...@freebsd.org; byc...@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 1 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- unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list http://li
Re: kern/189720: [ipfw] [patch] pps action for ipfw
What is the "use case" of this addition? Is this objective to limit the mischief on a certain port, for example ntp or port 53? I can appreciate the need to limit the number of packets during, say a DDOS event, but I'm struggling with why I would want less that 1 packet per second. Is the idea of pps meant to remove the need of dummynet where it is used in almost trivial cases? Though if this were the case, then bps (bits per second) may be more useful? Dewayne. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
