On Thursday 2011-10-13 13:23, Michal Kubeček wrote: >On Thursday 13 of October 2011, Jan Engelhardt wrote: >> >Not exactly. With "--limit-burst 1", no more than one packet per >> >jiffy can pass the test. You may have only 30 NEW packets per >> >second but it doesn't mean one packet every 1/30 s. And if there >> >are two (or more) NEW packets within one jiffy, only the first >> >passes the first rule. >> >> One packet per time quantum (which is 1 second here, not 1 jiffy). > >I don't think so. With "--limit 2000/s --limit-burst 1" I can pass much >more than one packet per second (but no more than 1000 per second with >HZ=1000). Well, burst does not specify any rate, so claiming "per second" (or "per jiffy") does not make sense anyway. As per the manpage, it replenishes the available credit. It's just that the math is not very intuitive. In a way it specifies the window for calculation. --limit n/s --limit-burst 1, IIRC, enforces 1 packet per 1/n seconds strictly, while --limit n/s --limit-burst n allows for spreading n over 1 second. (The two most common uses.) --limit 2000/s should always give you 2000 packets somehow distributed over 1 second for any burst value <= 2000. The fact that it does not (you observe 1000/s) hints towards what I said earlier that high-rate matching in xt_limit and xt_hashlimit has inaccuracies. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
