[NF-HIPAC] Performance test results available

[NF-HIPAC] Performance test results available

[nf]

Hi,

We now have the results of some basic performance tests available on our web 
page. The test compares the performance of the iptables filter table to the 
performance of nf-hipac. Results are pretty impressive :-)

You can find the performance test results on our web page http://www.hipac.org
The releases can be downloaded from http://sourceforge.net/projects/nf-hipac/

For people who don't know nf-hipac yet:
nf-hipac aims to become a drop-in replacement for the iptables packet 
filtering module. It implements a novel framework for packet classification 
which uses an advanced algorithm to reduce the number of memory lookups per 
packet. The module is ideal for environments where large rulesets and/or
high bandwidth networks are involved.

Enjoy,

+-----------------------+----------------------+
|   Michael Bellion     |     Thomas Heinz     |
| <mbellion@hipac.org>  |  <creatix@hipac.org> |
+-----------------------+----------------------+

Re: [NF-HIPAC] Performance test results available

[Emmanuel Fleury]

Hi,

First, your results are really impressive in comparison to iptables...

I was wandering two things:

1) How does behave the CPU load during your test ?

As you are using very powerful machines (which is not often the case in
reality for firewalls and router), I was really wandering how the CPU
power can affect your method.

2) How much space was used to store each of the rulessets ?

Your representation seems to be compact, but I was wandering how ?
Maybe a comparison with the size of the iptables rulessets could
be relevant.

Regards
-- 
Emmanuel

When all else fails, read the instructions.
   -- Allen's Axiom

Re: [NF-HIPAC] Performance test results available

[mbellion]

Hi,

> 1) How does behave the CPU load during your test ?
> As you are using very powerful machines (which is not often the case in
> reality for firewalls and router), I was really wandering how the CPU
> power can affect your method.

Sorry, we don't have information about that available. We will have to do 
additional tests with less powerfull machines to examine that.

> 2) How much space was used to store each of the rulessets ?
> Your representation seems to be compact, but I was wandering how ?
> Maybe a comparison with the size of the iptables rulessets could
> be relevant.

The memory usage of our algorithm isn't that much dependent on the number of 
rules. It's much more dependent on the structure of the ruleset and the type 
of the used rules. It is e.g. possible that a ruleset with 100 rules uses 
more memory than a ruleset with 10.000 rules. There are case where nf-hipac 
uses less memory than iptables and there are case where nf-hipac consumes 
really a huge amount of memory.
It's not possible to easily describe the memory usage of nf-hipac. It depends 
on a lot of factors and interactions of different rule types.
Our algorithm is designed to have an acceptable memory usage for realistic 
rulesets. In the tests we made we didn't use realistic rulesets, but 
completely synthetic ones in order to simultate theoretical worst case 
performance of the algorithm.
We haven't wrote down memory usage during the tests, so we don't have the 
numbers available. But as already said, the rulesets were completely 
syntetic, so the numbers probably don't say much about the algorithm anyway.
I only remember that memory usage was pretty huge with that synthetic 
rulesets.

Michael Bellion

Re: [NF-HIPAC] Performance test results available

[Roberto Nibali]

Hello,

>>1) How does behave the CPU load during your test ?
>>As you are using very powerful machines (which is not often the case in
>>reality for firewalls and router), I was really wandering how the CPU
>>power can affect your method.

It is certainly often the case in daily business. But concerning CPU load I did 
some testing this weekend and I will continue testing. Results are phantastic so 
far. Almost no performance issues.

> Sorry, we don't have information about that available. We will have to do 
> additional tests with less powerfull machines to examine that.

Yes, do that.

>>2) How much space was used to store each of the rulessets ?

cat /proc/slabinfo

It's 64 bytes per rule, plus an additional 64 when inserting the first ~1000 
slab objects, depending on the tree balance.

>>Your representation seems to be compact, but I was wandering how ?
>>Maybe a comparison with the size of the iptables rulessets could
>>be relevant.

I've done it and it is amazing. A short overview gave me following rough outline 
with a PIII 500MHz 512KB L2, kernel 2.4.20pre8:

raw TCP (MTU sized packets) throughput                     : 88.5 Mbit/s
10000 non-matching rules before the matching one (iptables):  3.4 Mbit/s
10000 non-matching rules before the matching one (nf-hipac): 85.2 Mbit/s

> The memory usage of our algorithm isn't that much dependent on the number of 
> rules. It's much more dependent on the structure of the ruleset and the type 
> of the used rules. It is e.g. possible that a ruleset with 100 rules uses 
> more memory than a ruleset with 10.000 rules. There are case where nf-hipac 
> uses less memory than iptables and there are case where nf-hipac consumes 
> really a huge amount of memory.

Memory is not an issue nowadays :)

And you can always check /proc/net/nf-hipac

> It's not possible to easily describe the memory usage of nf-hipac. It depends 
> on a lot of factors and interactions of different rule types.
> Our algorithm is designed to have an acceptable memory usage for realistic 
> rulesets. In the tests we made we didn't use realistic rulesets, but 
> completely synthetic ones in order to simultate theoretical worst case 
> performance of the algorithm.

For some people 300 rules are realistic, for our company 3000+ rules are realistic.

> We haven't wrote down memory usage during the tests, so we don't have the 
> numbers available. But as already said, the rulesets were completely 
> syntetic, so the numbers probably don't say much about the algorithm anyway.
> I only remember that memory usage was pretty huge with that synthetic 
> rulesets.

I will conduct further test this coming weekend. An thursday I will present some 
result at the linuxday.lu expo in Luxembourg.

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Re: [NF-HIPAC] Performance test results available

[netfilter]

[-- Attachment #1: Type: text/plain, Size: 395 bytes --]

Can a conntrack/nat helper alter the timeout of the master connection?
In my case it's a UDP connection and the reply to the UDP request can
be as long as 5 minutes in replying.  The protocol I am working with
requires a helper to set up related connections, but I am wondering if
I can also extend the timeout of the master connection in the helper.

Thanx,
b.

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]