kern/189720: [ipfw] [patch] pps action for ipfw

[bycn82]

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:julian at freebsd.org]
> Sent: 30 May, 2014 22:40
> To: bycn82; 'Luigi Rizzo'; freebsd-ipfw at 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 at freebsd.org [mailto:owner-freebsd-
> >> ipfw at freebsd.org] On Behalf Of 'Luigi Rizzo'
> >> Sent: 29 May, 2014 23:20
> >> To: freebsd-ipfw at 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' <rizzo at iet.unipi.it>
> >> To: bycn82 <bycn82 at gmail.com>
> >> Cc: bug-followup at 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 at iet.unipi.it]  > Sent: 29 May, 2014 22:12  >
> To:
> >> bug-followup at FreeBSD.org; bycn82 at 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 at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> >> To unsubscribe, send any mail to "freebsd-ipfw-
> unsubscribe at freebsd.org"
> > _______________________________________________
> > freebsd-ipfw at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
> >