So, I have learned alot in this topic, thank to all that answered. And if I understand correctly, beside the error in overflow handling mentioned in the Nicolas's paper, we only get a high accuracy with limit or hashlimit if HZ be very high, to avoid the colision on concurrent packets arriving in the same slice of 10ms, 4ms or 1ms, but changing the HZ can be some side effects. So, can be useful to submit the Nicolas's patch again :) In this meantime, I'll try rateest and find out how it can fit my needs. Thanks, Klaubert On Mon, May 14, 2012 at 10:34 PM, Jan Engelhardt <jengelh@xxxxxxx> wrote: > On Tuesday 2012-05-15 00:45, Payam Chychi wrote: > >>> I'm playing with match modules limit and hashlimit, and they appear to >>> be limited to match a maximun 100/sec. If I use hashlimit with no >>> "--hashlimit-mode" I get the same, a max of 100/sec, even if I set for >>> exemple to 250/sec. My command setting the 250/sec is accepted, with >>> no error, but test show only 100 match/sec. >>> >>> Is this a hard limit of this modules, or I can go above this in some way? >> >>limit and hashlimit have never worked properly > > Best is to collect packets using -j RATEEST and then matching > against it with -m rateest. -- 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
