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 t
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 t
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
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_000
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.
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 th
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