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' <ri...@iet.unipi.it>
To: bycn82 <byc...@gmail.com>
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 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-
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"
