Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 May 2014 11:12:37 +0800
From:      Julian Elischer <julian@freebsd.org>
To:        bycn82 <bycn82@gmail.com>, "'Luigi Rizzo'" <rizzo@iet.unipi.it>, freebsd-ipfw@FreeBSD.org
Subject:   Re: kern/189720: [ipfw] [patch] pps action for ipfw
Message-ID:  <538948A5.2050003@freebsd.org>
In-Reply-To: <000001cf7c18$c6cbd460$54637d20$@gmail.com>
References:  <201405291520.s4TFK124032925@freefall.freebsd.org> <007f01cf7b52$efd8a0c0$cf89e240$@gmail.com> <53889829.6030307@freebsd.org> <000001cf7c18$c6cbd460$54637d20$@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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' <rizzo@iet.unipi.it>
>>>> To: bycn82 <bycn82@gmail.com>
>>>> 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"
>>>
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?538948A5.2050003>