Mailing List Archive: NTop: Misc

nProbe hash size and allocation

Index | Next | Previous | View Threaded

daa at open

Mar 10, 2011, 2:12 AM

Post #1 of 13 (1138 views)
Permalink

nProbe hash size and allocation

Ciao Luca and community,

I have a question about the allocation of the hash in nProbe.

On page 28 of your documentation (section 2.4 Tuning nProbe
Performance), you state that the hash size is static, but on the
footnote you mention that the hash "can grow as needed according to
traffic". Does this mean that one have to set the -w flag according to
the traffic (which makes sense) or does nProbe grow his hash according
to traffic?

Sorry about this fuzzy question, but in my eyes the footnote contradicts
the statement of static allocation.

Thanks a lot for your clarification.

Cheers

Dani
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

yuri at ntop

Mar 10, 2011, 2:16 AM

Post #2 of 13 (1121 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

Daniel
the meaning of "hash size is static" means that once you decide its size,
this size is fixed.
The meaning of "tunable" means that is the default hash size does not fit
your requirements (due traffic conditions), you can choose to set the size
you prefer/need, but this allocation is done up on nprobe statup.
Regards, Yuri

On Thu, 10 Mar 2011 11:12:15 +0100, Daniel Aschwanden <daa [at] open> wrote:
> Ciao Luca and community,
>
> I have a question about the allocation of the hash in nProbe.
>
> On page 28 of your documentation (section 2.4 Tuning nProbe
> Performance), you state that the hash size is static, but on the
> footnote you mention that the hash "can grow as needed according to
> traffic". Does this mean that one have to set the -w flag according to
> the traffic (which makes sense) or does nProbe grow his hash according
> to traffic?
>
> Sorry about this fuzzy question, but in my eyes the footnote contradicts
> the statement of static allocation.
>
> Thanks a lot for your clarification.
>
> Cheers
>
> Dani
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

--
Yuri Francalacci
yuri [at] ntop
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

mam at open

Mar 10, 2011, 2:31 AM

Post #3 of 13 (1119 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

On 10.03.2011 11:16, Yuri Francalacci wrote:
> Daniel
> the meaning of "hash size is static" means that once you decide its size,
> this size is fixed.
> The meaning of "tunable" means that is the default hash size does not fit
> your requirements (due traffic conditions),

and how can you realize that you run into that condition? I mean, will
nprobe log somewhere flow accounting losses due to a too small hash size?
Thanks,
Maurizio

you can choose to set the size
> you prefer/need, but this allocation is done up on nprobe statup.
> Regards, Yuri
>
>
> On Thu, 10 Mar 2011 11:12:15 +0100, Daniel Aschwanden<daa [at] open> wrote:
>> Ciao Luca and community,
>>
>> I have a question about the allocation of the hash in nProbe.
>>
>> On page 28 of your documentation (section 2.4 Tuning nProbe
>> Performance), you state that the hash size is static, but on the
>> footnote you mention that the hash "can grow as needed according to
>> traffic". Does this mean that one have to set the -w flag according to
>> the traffic (which makes sense) or does nProbe grow his hash according
>> to traffic?
>>
>> Sorry about this fuzzy question, but in my eyes the footnote contradicts
>> the statement of static allocation.
>>
>> Thanks a lot for your clarification.
>>
>> Cheers
>>
>> Dani
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>

--
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

deri at ntop

Mar 13, 2011, 3:32 AM

Post #4 of 13 (1092 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

Hi all,
let me explain this in detail.

A hash is a contiguous array of list pointers. Incoming flows are hashed (using the 5 tuples) and the obtained hash_id value is used to identify the array index. As hashes are a way to "compress" information, it might happen that two different flows have the same hash_id, thus the list pointer is used to maintain a list of "collisions". With -w you set the array size, whereas the list size can be as long as necessary. This said, in order to set an upper limit, nprobe via

[--max-num-flows|-M] <max num flows>| Limit the number of active flows

defines the max number of flows it can handle

This said, you must choose -w according to the number of flows you expect to have in your network. The value must be a good compromise between number of flows and memory usage. We suggest to set it to twice the expected number of concurrent flows, but as I have explained it, in case of large flow number, you won't drop flows (except you will specify a low value for -M) but just have a slower probe as it has to maintain long collision lists. If you start nprobe with "-b 1" you can see some stats like

13/Mar/2011 11:30:13 [nprobe.c:1475] Flow Buckets: [active=11401][allocated=11401][toBeExported=0][frags=0]
13/Mar/2011 11:30:13 [nprobe.c:1511] Processed packets: 24834 (max bucket search: 3)

In this case nProbe says that
1. your flow cache has 11401 entries (= flows)
2. the longest collision list is 3 that's still acceptable. If you exceed 8, you better use a bigger value for -w next time you start nProbe.

I hope I have clarified the details.

Regards Luca

On Mar 10, 2011, at 11:31 AM, Maurizio Molina wrote:

>
>
> On 10.03.2011 11:16, Yuri Francalacci wrote:
>> Daniel
>> the meaning of "hash size is static" means that once you decide its size,
>> this size is fixed.
>> The meaning of "tunable" means that is the default hash size does not fit
>> your requirements (due traffic conditions),
>
> and how can you realize that you run into that condition? I mean, will nprobe log somewhere flow accounting losses due to a too small hash size?
> Thanks,
> Maurizio
>
> you can choose to set the size
>> you prefer/need, but this allocation is done up on nprobe statup.
>> Regards, Yuri
>>
>>
>> On Thu, 10 Mar 2011 11:12:15 +0100, Daniel Aschwanden<daa [at] open> wrote:
>>> Ciao Luca and community,
>>>
>>> I have a question about the allocation of the hash in nProbe.
>>>
>>> On page 28 of your documentation (section 2.4 Tuning nProbe
>>> Performance), you state that the hash size is static, but on the
>>> footnote you mention that the hash "can grow as needed according to
>>> traffic". Does this mean that one have to set the -w flag according to
>>> the traffic (which makes sense) or does nProbe grow his hash according
>>> to traffic?
>>>
>>> Sorry about this fuzzy question, but in my eyes the footnote contradicts
>>> the statement of static allocation.
>>>
>>> Thanks a lot for your clarification.
>>>
>>> Cheers
>>>
>>> Dani
>>> _______________________________________________
>>> Ntop-misc mailing list
>>> Ntop-misc [at] listgateway
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>
> --
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

---
Due to lack of interest, tomorrow is cancelled - Kaiser Chiefs

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

daa at open

Apr 12, 2011, 8:43 AM

Post #5 of 13 (1019 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

Just another small question about the hash size of nprobe:

Is this size in terms of "buckets" (positions) or in terms of bytes/bits?

It would be just good to know to do some basic consideration.

Regards,
Daniel

> Hi all,
> let me explain this in detail.
>
> A hash is a contiguous array of list pointers. Incoming flows are hashed (using
> the 5 tuples) and the obtained hash_id value is used to identify the array
> index. As hashes are a way to "compress" information, it might happen that two
> different flows have the same hash_id, thus the list pointer is used to
> maintain a list of "collisions". With -w you set the array size, whereas the
> list size can be as long as necessary. This said, in order to set an upper
> limit, nprobe via
>
> [--max-num-flows|-M] <max num flows>| Limit the number of active flows
>
> defines the max number of flows it can handle
>
> This said, you must choose -w according to the number of flows you expect to
> have in your network. The value must be a good compromise between number of
> flows and memory usage. We suggest to set it to twice the expected number of
> concurrent flows, but as I have explained it, in case of large flow number, you
> won't drop flows (except you will specify a low value for -M) but just have a
> slower probe as it has to maintain long collision lists. If you start nprobe
> with "-b 1" you can see some stats like
>
> 13/Mar/2011 11:30:13 [nprobe.c:1475] Flow Buckets:
> [active=11401][allocated=11401][toBeExported=0][frags=0]
> 13/Mar/2011 11:30:13 [nprobe.c:1511] Processed packets: 24834 (max bucket
> search: 3)
>
> In this case nProbe says that
> 1. your flow cache has 11401 entries (= flows)
> 2. the longest collision list is 3 that's still acceptable. If you exceed 8,
> you better use a bigger value for -w next time you start nProbe.
>
> I hope I have clarified the details.
>
> Regards Luca
>
> On Mar 10, 2011, at 11:31 AM, Maurizio Molina wrote:
>
>>
>>
>> On 10.03.2011 11:16, Yuri Francalacci wrote:
>>> Daniel
>>> the meaning of "hash size is static" means that once you decide its size,
>>> this size is fixed.
>>> The meaning of "tunable" means that is the default hash size does not fit
>>> your requirements (due traffic conditions),
>>
>> and how can you realize that you run into that condition? I mean, will nprobe
>> log somewhere flow accounting losses due to a too small hash size?
>> Thanks,
>> Maurizio
>>
>> you can choose to set the size
>>> you prefer/need, but this allocation is done up on nprobe statup.
>>> Regards, Yuri
>>>
>>>
>>> On Thu, 10 Mar 2011 11:12:15 +0100, Daniel Aschwanden<d...@open.ch> wrote:
>>>> Ciao Luca and community,
>>>>
>>>> I have a question about the allocation of the hash in nProbe.
>>>>
>>>> On page 28 of your documentation (section 2.4 Tuning nProbe
>>>> Performance), you state that the hash size is static, but on the
>>>> footnote you mention that the hash "can grow as needed according to
>>>> traffic". Does this mean that one have to set the -w flag according to
>>>> the traffic (which makes sense) or does nProbe grow his hash according
>>>> to traffic?
>>>>
>>>> Sorry about this fuzzy question, but in my eyes the footnote contradicts
>>>> the statement of static allocation.
>>>>
>>>> Thanks a lot for your clarification.
>>>>
>>>> Cheers
>>>>
>>>> Dani
>>>> _______________________________________________
>>>> Ntop-misc mailing list
>>>> Ntop-misc [at] listgateway
>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>>
>>
>> --
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> ---
> Due to lack of interest, tomorrow is cancelled - Kaiser Chiefs
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

- --
daniel aschwanden
junior engineer

open systems ag
raeffelstrasse 29
ch-8045 zurich
t: +41 44 455 74 00
f: +41 44 455 74 01
daa [at] open

http://www.open.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk2kczgACgkQxIzmH53Qg6GtkAD/RKcAvnEGn0jCh59dKXOXrZPN
QJ4CvSad+uTJg+k2ZRQA/0Aw8KBZRA3QZaS1cEmHldM8CrMbfLQr1CjOvDJ+Ww7R
=flaW
-----END PGP SIGNATURE-----
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

deri at ntop

Apr 12, 2011, 8:55 AM

Post #6 of 13 (1021 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

Daniel
is in term of positions, not bytes

Luca

On Apr 12, 2011, at 5:43 PM, Daniel Aschwanden wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> Just another small question about the hash size of nprobe:
>
> Is this size in terms of "buckets" (positions) or in terms of bytes/bits?
>
> It would be just good to know to do some basic consideration.
>
> Regards,
> Daniel
>
>> Hi all,
>> let me explain this in detail.
>>
>> A hash is a contiguous array of list pointers. Incoming flows are hashed (using
>> the 5 tuples) and the obtained hash_id value is used to identify the array
>> index. As hashes are a way to "compress" information, it might happen that two
>> different flows have the same hash_id, thus the list pointer is used to
>> maintain a list of "collisions". With -w you set the array size, whereas the
>> list size can be as long as necessary. This said, in order to set an upper
>> limit, nprobe via
>>
>> [--max-num-flows|-M] <max num flows>| Limit the number of active flows
>>
>> defines the max number of flows it can handle
>>
>> This said, you must choose -w according to the number of flows you expect to
>> have in your network. The value must be a good compromise between number of
>> flows and memory usage. We suggest to set it to twice the expected number of
>> concurrent flows, but as I have explained it, in case of large flow number, you
>> won't drop flows (except you will specify a low value for -M) but just have a
>> slower probe as it has to maintain long collision lists. If you start nprobe
>> with "-b 1" you can see some stats like
>>
>> 13/Mar/2011 11:30:13 [nprobe.c:1475] Flow Buckets:
>> [active=11401][allocated=11401][toBeExported=0][frags=0]
>> 13/Mar/2011 11:30:13 [nprobe.c:1511] Processed packets: 24834 (max bucket
>> search: 3)
>>
>> In this case nProbe says that
>> 1. your flow cache has 11401 entries (= flows)
>> 2. the longest collision list is 3 that's still acceptable. If you exceed 8,
>> you better use a bigger value for -w next time you start nProbe.
>>
>> I hope I have clarified the details.
>>
>> Regards Luca
>>
>> On Mar 10, 2011, at 11:31 AM, Maurizio Molina wrote:
>>
>>>
>>>
>>> On 10.03.2011 11:16, Yuri Francalacci wrote:
>>>> Daniel
>>>> the meaning of "hash size is static" means that once you decide its size,
>>>> this size is fixed.
>>>> The meaning of "tunable" means that is the default hash size does not fit
>>>> your requirements (due traffic conditions),
>>>
>>> and how can you realize that you run into that condition? I mean, will nprobe
>>> log somewhere flow accounting losses due to a too small hash size?
>>> Thanks,
>>> Maurizio
>>>
>>> you can choose to set the size
>>>> you prefer/need, but this allocation is done up on nprobe statup.
>>>> Regards, Yuri
>>>>
>>>>
>>>> On Thu, 10 Mar 2011 11:12:15 +0100, Daniel Aschwanden<d...@open.ch> wrote:
>>>>> Ciao Luca and community,
>>>>>
>>>>> I have a question about the allocation of the hash in nProbe.
>>>>>
>>>>> On page 28 of your documentation (section 2.4 Tuning nProbe
>>>>> Performance), you state that the hash size is static, but on the
>>>>> footnote you mention that the hash "can grow as needed according to
>>>>> traffic". Does this mean that one have to set the -w flag according to
>>>>> the traffic (which makes sense) or does nProbe grow his hash according
>>>>> to traffic?
>>>>>
>>>>> Sorry about this fuzzy question, but in my eyes the footnote contradicts
>>>>> the statement of static allocation.
>>>>>
>>>>> Thanks a lot for your clarification.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Dani
>>>>> _______________________________________________
>>>>> Ntop-misc mailing list
>>>>> Ntop-misc [at] listgateway
>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>>>
>>>
>>> --
>>> _______________________________________________
>>> Ntop-misc mailing list
>>> Ntop-misc [at] listgateway
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>> ---
>> Due to lack of interest, tomorrow is cancelled - Kaiser Chiefs
>>
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> - --
> daniel aschwanden
> junior engineer
>
> open systems ag
> raeffelstrasse 29
> ch-8045 zurich
> t: +41 44 455 74 00
> f: +41 44 455 74 01
> daa [at] open
>
> http://www.open.ch
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk2kczgACgkQxIzmH53Qg6GtkAD/RKcAvnEGn0jCh59dKXOXrZPN
> QJ4CvSad+uTJg+k2ZRQA/0Aw8KBZRA3QZaS1cEmHldM8CrMbfLQr1CjOvDJ+Ww7R
> =flaW
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

---
If you can not measure it, you can not improve it - Lord Kelvin

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

daa at open

Apr 19, 2011, 6:24 AM

Post #7 of 13 (1048 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

I'm still struggling with the hash of nprobe (version 6.3.0).

Luca suggested to increase the hash size, if there is a max. bucket
search over 8.

I've in total around 550'000 active flow buckets and I see hardly any
difference in terms of max. bucket search, if I vary the hash size from
2^17 to 2^23.

======================================================================
with -w 131072, I get the following output from nprobe:
======================================================================
19/Apr/2011 15:00:41 [nprobe.c:1459] ---------------------------------
19/Apr/2011 15:00:41 [nprobe.c:1460] Average traffic: [118.154 K pps][73
Mb/sec]
19/Apr/2011 15:00:41 [nprobe.c:1465] Current traffic: [107.855 K pps][67
Mb/sec]
19/Apr/2011 15:00:41 [nprobe.c:1471] Current flow export rate: [58351.3
flows/sec]
19/Apr/2011 15:00:41 [nprobe.c:1474] Flow drops: [export queue too
long=0][too many flows=0]
19/Apr/2011 15:00:41 [nprobe.c:1480] Flow Buckets:
[active=570228][allocated=570228][toBeExported=0][frags=0]
19/Apr/2011 15:00:41 [nprobe.c:1516] Processed packets: 15478149 (max
bucket search: 16)
19/Apr/2011 15:00:41 [nprobe.c:1519] Flow Collection: [collected pkts:
0][processed flows: 0]
19/Apr/2011 15:00:41 [nprobe.c:222] Packet stats: 15478229/0 pkts
rcvd/dropped [0.0%] [Last 323545/0 pkts rcvd/dropped]
19/Apr/2011 15:00:43 [nprobe.c:1459] ---------------------------------
19/Apr/2011 15:00:43 [nprobe.c:1460] Average traffic: [118.735 K pps][73
Mb/sec]
19/Apr/2011 15:00:43 [nprobe.c:1465] Current traffic: [156.785 K pps][97
Mb/sec]
19/Apr/2011 15:00:43 [nprobe.c:1471] Current flow export rate: [59780.5
flows/sec]
19/Apr/2011 15:00:43 [nprobe.c:1474] Flow drops: [export queue too
long=0][too many flows=0]
19/Apr/2011 15:00:43 [nprobe.c:1480] Flow Buckets:
[active=562104][allocated=607792][toBeExported=45688][frags=0]
19/Apr/2011 15:00:43 [nprobe.c:1516] Processed packets: 15791715 (max
bucket search: 15)
19/Apr/2011 15:00:43 [nprobe.c:1519] Flow Collection: [collected pkts:
0][processed flows: 0]
19/Apr/2011 15:00:43 [nprobe.c:222] Packet stats: 15791810/0 pkts
rcvd/dropped [0.0%] [Last 313581/0 pkts rcvd/dropped]

======================================================================
and with -w 8388608:
======================================================================
19/Apr/2011 15:15:22 [nprobe.c:1459] ---------------------------------
19/Apr/2011 15:15:22 [nprobe.c:1460] Average traffic: [117.322 K pps][72
Mb/sec]
19/Apr/2011 15:15:22 [nprobe.c:1465] Current traffic: [110.342 K pps][69
Mb/sec]
19/Apr/2011 15:15:22 [nprobe.c:1471] Current flow export rate: [64136.3
flows/sec]
19/Apr/2011 15:15:22 [nprobe.c:1474] Flow drops: [export queue too
long=0][too many flows=0]
19/Apr/2011 15:15:22 [nprobe.c:1480] Flow Buckets:
[active=540968][allocated=540968][toBeExported=0][frags=0]
19/Apr/2011 15:15:22 [nprobe.c:1516] Processed packets: 11614885 (max
bucket search: 19)
19/Apr/2011 15:15:22 [nprobe.c:1519] Flow Collection: [collected pkts:
0][processed flows: 0]
19/Apr/2011 15:15:22 [nprobe.c:222] Packet stats: 11615012/0 pkts
rcvd/dropped [0.0%] [Last 331026/0 pkts rcvd/dropped]
19/Apr/2011 15:15:25 [nprobe.c:1459] ---------------------------------
19/Apr/2011 15:15:25 [nprobe.c:1460] Average traffic: [117.143 K pps][72
Mb/sec]
19/Apr/2011 15:15:25 [nprobe.c:1465] Current traffic: [111.232 K pps][69
Mb/sec]
19/Apr/2011 15:15:25 [nprobe.c:1471] Current flow export rate: [62210.0
flows/sec]
19/Apr/2011 15:15:25 [nprobe.c:1474] Flow drops: [export queue too
long=0][too many flows=0]
19/Apr/2011 15:15:25 [nprobe.c:1480] Flow Buckets:
[active=521688][allocated=521688][toBeExported=0][frags=0]
19/Apr/2011 15:15:25 [nprobe.c:1516] Processed packets: 11948651 (max
bucket search: 16)
19/Apr/2011 15:15:25 [nprobe.c:1519] Flow Collection: [collected pkts:
0][processed flows: 0]
19/Apr/2011 15:15:25 [nprobe.c:222] Packet stats: 11948778/0 pkts
rcvd/dropped [0.0%] [Last 333766/0 pkts rcvd/dropped]

What should I do to decrease the max. bucket search. Do I understand it
correctly, that the max. bucket search is just a list of the hash
collisions? If yes, a bigger hash size should normally lead to less
collisions if the hash is well distributed across the hash domain?

I'm really glad about any remarks and suggestions.

Cheers,
Dani Aschwanden

- --
daniel aschwanden
junior engineer

open systems ag
raeffelstrasse 29
ch-8045 zurich
t: +41 44 455 74 00
f: +41 44 455 74 01
daa [at] open

http://www.open.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk2tjQ8ACgkQxIzmH53Qg6FomwD/WuGVICd8FBw8Mk3layzZuJQ4
u5/DOunaoknh860fuhAA/0yit6ucLBjEI8M37A+uwvxV6MjZdyLR9bpqOnTenfI0
=uIUz
-----END PGP SIGNATURE-----
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

deri at ntop

Apr 19, 2011, 8:33 AM

Post #8 of 13 (1010 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

Daniel
if you have 100k concurrent flows, -w 256000 will do the job

Luca

On Apr 19, 2011, at 3:24 PM, Daniel Aschwanden wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> I'm still struggling with the hash of nprobe (version 6.3.0).
>
> Luca suggested to increase the hash size, if there is a max. bucket
> search over 8.
>
> I've in total around 550'000 active flow buckets and I see hardly any
> difference in terms of max. bucket search, if I vary the hash size from
> 2^17 to 2^23.
>
> ======================================================================
> with -w 131072, I get the following output from nprobe:
> ======================================================================
> 19/Apr/2011 15:00:41 [nprobe.c:1459] ---------------------------------
> 19/Apr/2011 15:00:41 [nprobe.c:1460] Average traffic: [118.154 K pps][73
> Mb/sec]
> 19/Apr/2011 15:00:41 [nprobe.c:1465] Current traffic: [107.855 K pps][67
> Mb/sec]
> 19/Apr/2011 15:00:41 [nprobe.c:1471] Current flow export rate: [58351.3
> flows/sec]
> 19/Apr/2011 15:00:41 [nprobe.c:1474] Flow drops: [export queue too
> long=0][too many flows=0]
> 19/Apr/2011 15:00:41 [nprobe.c:1480] Flow Buckets:
> [active=570228][allocated=570228][toBeExported=0][frags=0]
> 19/Apr/2011 15:00:41 [nprobe.c:1516] Processed packets: 15478149 (max
> bucket search: 16)
> 19/Apr/2011 15:00:41 [nprobe.c:1519] Flow Collection: [collected pkts:
> 0][processed flows: 0]
> 19/Apr/2011 15:00:41 [nprobe.c:222] Packet stats: 15478229/0 pkts
> rcvd/dropped [0.0%] [Last 323545/0 pkts rcvd/dropped]
> 19/Apr/2011 15:00:43 [nprobe.c:1459] ---------------------------------
> 19/Apr/2011 15:00:43 [nprobe.c:1460] Average traffic: [118.735 K pps][73
> Mb/sec]
> 19/Apr/2011 15:00:43 [nprobe.c:1465] Current traffic: [156.785 K pps][97
> Mb/sec]
> 19/Apr/2011 15:00:43 [nprobe.c:1471] Current flow export rate: [59780.5
> flows/sec]
> 19/Apr/2011 15:00:43 [nprobe.c:1474] Flow drops: [export queue too
> long=0][too many flows=0]
> 19/Apr/2011 15:00:43 [nprobe.c:1480] Flow Buckets:
> [active=562104][allocated=607792][toBeExported=45688][frags=0]
> 19/Apr/2011 15:00:43 [nprobe.c:1516] Processed packets: 15791715 (max
> bucket search: 15)
> 19/Apr/2011 15:00:43 [nprobe.c:1519] Flow Collection: [collected pkts:
> 0][processed flows: 0]
> 19/Apr/2011 15:00:43 [nprobe.c:222] Packet stats: 15791810/0 pkts
> rcvd/dropped [0.0%] [Last 313581/0 pkts rcvd/dropped]
>
> ======================================================================
> and with -w 8388608:
> ======================================================================
> 19/Apr/2011 15:15:22 [nprobe.c:1459] ---------------------------------
> 19/Apr/2011 15:15:22 [nprobe.c:1460] Average traffic: [117.322 K pps][72
> Mb/sec]
> 19/Apr/2011 15:15:22 [nprobe.c:1465] Current traffic: [110.342 K pps][69
> Mb/sec]
> 19/Apr/2011 15:15:22 [nprobe.c:1471] Current flow export rate: [64136.3
> flows/sec]
> 19/Apr/2011 15:15:22 [nprobe.c:1474] Flow drops: [export queue too
> long=0][too many flows=0]
> 19/Apr/2011 15:15:22 [nprobe.c:1480] Flow Buckets:
> [active=540968][allocated=540968][toBeExported=0][frags=0]
> 19/Apr/2011 15:15:22 [nprobe.c:1516] Processed packets: 11614885 (max
> bucket search: 19)
> 19/Apr/2011 15:15:22 [nprobe.c:1519] Flow Collection: [collected pkts:
> 0][processed flows: 0]
> 19/Apr/2011 15:15:22 [nprobe.c:222] Packet stats: 11615012/0 pkts
> rcvd/dropped [0.0%] [Last 331026/0 pkts rcvd/dropped]
> 19/Apr/2011 15:15:25 [nprobe.c:1459] ---------------------------------
> 19/Apr/2011 15:15:25 [nprobe.c:1460] Average traffic: [117.143 K pps][72
> Mb/sec]
> 19/Apr/2011 15:15:25 [nprobe.c:1465] Current traffic: [111.232 K pps][69
> Mb/sec]
> 19/Apr/2011 15:15:25 [nprobe.c:1471] Current flow export rate: [62210.0
> flows/sec]
> 19/Apr/2011 15:15:25 [nprobe.c:1474] Flow drops: [export queue too
> long=0][too many flows=0]
> 19/Apr/2011 15:15:25 [nprobe.c:1480] Flow Buckets:
> [active=521688][allocated=521688][toBeExported=0][frags=0]
> 19/Apr/2011 15:15:25 [nprobe.c:1516] Processed packets: 11948651 (max
> bucket search: 16)
> 19/Apr/2011 15:15:25 [nprobe.c:1519] Flow Collection: [collected pkts:
> 0][processed flows: 0]
> 19/Apr/2011 15:15:25 [nprobe.c:222] Packet stats: 11948778/0 pkts
> rcvd/dropped [0.0%] [Last 333766/0 pkts rcvd/dropped]
>
> What should I do to decrease the max. bucket search. Do I understand it
> correctly, that the max. bucket search is just a list of the hash
> collisions? If yes, a bigger hash size should normally lead to less
> collisions if the hash is well distributed across the hash domain?
>
> I'm really glad about any remarks and suggestions.
>
> Cheers,
> Dani Aschwanden
>
> - --
> daniel aschwanden
> junior engineer
>
> open systems ag
> raeffelstrasse 29
> ch-8045 zurich
> t: +41 44 455 74 00
> f: +41 44 455 74 01
> daa [at] open
>
> http://www.open.ch
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk2tjQ8ACgkQxIzmH53Qg6FomwD/WuGVICd8FBw8Mk3layzZuJQ4
> u5/DOunaoknh860fuhAA/0yit6ucLBjEI8M37A+uwvxV6MjZdyLR9bpqOnTenfI0
> =uIUz
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

---
If you can not measure it, you can not improve it - Lord Kelvin

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

daa at open

Apr 19, 2011, 8:53 AM

Post #9 of 13 (1004 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Luca,

On 04/19/2011 05:33 PM, Luca Deri wrote:
> Daniel
> if you have 100k concurrent flows, -w 256000 will do the job
>
> Luca

Unfortunately not (-w 262144):

19/Apr/2011 17:40:39 [nprobe.c:1459] ---------------------------------
19/Apr/2011 17:40:39 [nprobe.c:1460] Average traffic: [105.431 K pps][68
Mb/sec]
19/Apr/2011 17:40:39 [nprobe.c:1465] Current traffic: [142.662 K pps][88
Mb/sec]
19/Apr/2011 17:40:39 [nprobe.c:1471] Current flow export rate: [12653.5
flows/sec]
19/Apr/2011 17:40:39 [nprobe.c:1474] Flow drops: [export queue too
long=0][too many flows=0]
19/Apr/2011 17:40:39 [nprobe.c:1480] Flow Buckets:
[active=532231][allocated=532231][toBeExported=0][frags=0]
19/Apr/2011 17:40:39 [nprobe.c:1516] Processed packets: 10332302 (max
bucket search: 14)
19/Apr/2011 17:40:39 [nprobe.c:1519] Flow Collection: [collected pkts:
0][processed flows: 0]
19/Apr/2011 17:40:39 [nprobe.c:222] Packet stats: 10332424/0 pkts
rcvd/dropped [0.0%] [Last 285324/0 pkts rcvd/dropped]
19/Apr/2011 17:40:42 [nprobe.c:1459] ---------------------------------
19/Apr/2011 17:40:42 [nprobe.c:1460] Average traffic: [105.521 K pps][68
Mb/sec]
19/Apr/2011 17:40:42 [nprobe.c:1465] Current traffic: [108.445 K pps][67
Mb/sec]
19/Apr/2011 17:40:42 [nprobe.c:1471] Current flow export rate: [29935.3
flows/sec]
19/Apr/2011 17:40:42 [nprobe.c:1474] Flow drops: [export queue too
long=0][too many flows=0]
19/Apr/2011 17:40:42 [nprobe.c:1480] Flow Buckets:
[active=605659][allocated=606136][toBeExported=477][frags=0]
19/Apr/2011 17:40:42 [nprobe.c:1516] Processed packets: 10657626 (max
bucket search: 16)
19/Apr/2011 17:40:42 [nprobe.c:1519] Flow Collection: [collected pkts:
0][processed flows: 0]
19/Apr/2011 17:40:42 [nprobe.c:222] Packet stats: 10657745/0 pkts
rcvd/dropped [0.0%] [Last 325321/0 pkts rcvd/dropped]

I know in theory the probability of occurance of list size > 16 should
be quite small.

I'm even more confused about that a obviously too big hash (2^23)
doesn't decrease the list size.

Any suggestions?

Thanks a lot!

Cheers, Dani

- --
daniel aschwanden
junior engineer

open systems ag
raeffelstrasse 29
ch-8045 zurich
t: +41 44 455 74 00
f: +41 44 455 74 01
daa [at] open

http://www.open.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk2tsBMACgkQxIzmH53Qg6HBtgD+Jxvl+v+YGAuwFgnq0b9fmsjR
Ve9Pa7yiAlaRO568asABAJTRmorB8vIggS/VqZ/JfUs255AZdMOHKmWEQDd9txPA
=rX7B
-----END PGP SIGNATURE-----
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

deri at ntop

Apr 19, 2011, 9:07 AM

Post #10 of 13 (1017 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

Daniel
it looks your traffic is not easy balance-able then. What kind of packets are you using?

Luca

On Apr 19, 2011, at 5:53 PM, Daniel Aschwanden wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi Luca,
>
> On 04/19/2011 05:33 PM, Luca Deri wrote:
>> Daniel
>> if you have 100k concurrent flows, -w 256000 will do the job
>>
>> Luca
>
> Unfortunately not (-w 262144):
>
> 19/Apr/2011 17:40:39 [nprobe.c:1459] ---------------------------------
> 19/Apr/2011 17:40:39 [nprobe.c:1460] Average traffic: [105.431 K pps][68
> Mb/sec]
> 19/Apr/2011 17:40:39 [nprobe.c:1465] Current traffic: [142.662 K pps][88
> Mb/sec]
> 19/Apr/2011 17:40:39 [nprobe.c:1471] Current flow export rate: [12653.5
> flows/sec]
> 19/Apr/2011 17:40:39 [nprobe.c:1474] Flow drops: [export queue too
> long=0][too many flows=0]
> 19/Apr/2011 17:40:39 [nprobe.c:1480] Flow Buckets:
> [active=532231][allocated=532231][toBeExported=0][frags=0]
> 19/Apr/2011 17:40:39 [nprobe.c:1516] Processed packets: 10332302 (max
> bucket search: 14)
> 19/Apr/2011 17:40:39 [nprobe.c:1519] Flow Collection: [collected pkts:
> 0][processed flows: 0]
> 19/Apr/2011 17:40:39 [nprobe.c:222] Packet stats: 10332424/0 pkts
> rcvd/dropped [0.0%] [Last 285324/0 pkts rcvd/dropped]
> 19/Apr/2011 17:40:42 [nprobe.c:1459] ---------------------------------
> 19/Apr/2011 17:40:42 [nprobe.c:1460] Average traffic: [105.521 K pps][68
> Mb/sec]
> 19/Apr/2011 17:40:42 [nprobe.c:1465] Current traffic: [108.445 K pps][67
> Mb/sec]
> 19/Apr/2011 17:40:42 [nprobe.c:1471] Current flow export rate: [29935.3
> flows/sec]
> 19/Apr/2011 17:40:42 [nprobe.c:1474] Flow drops: [export queue too
> long=0][too many flows=0]
> 19/Apr/2011 17:40:42 [nprobe.c:1480] Flow Buckets:
> [active=605659][allocated=606136][toBeExported=477][frags=0]
> 19/Apr/2011 17:40:42 [nprobe.c:1516] Processed packets: 10657626 (max
> bucket search: 16)
> 19/Apr/2011 17:40:42 [nprobe.c:1519] Flow Collection: [collected pkts:
> 0][processed flows: 0]
> 19/Apr/2011 17:40:42 [nprobe.c:222] Packet stats: 10657745/0 pkts
> rcvd/dropped [0.0%] [Last 325321/0 pkts rcvd/dropped]
>
> I know in theory the probability of occurance of list size > 16 should
> be quite small.
>
> I'm even more confused about that a obviously too big hash (2^23)
> doesn't decrease the list size.
>
> Any suggestions?
>
> Thanks a lot!
>
> Cheers, Dani
>
> - --
> daniel aschwanden
> junior engineer
>
> open systems ag
> raeffelstrasse 29
> ch-8045 zurich
> t: +41 44 455 74 00
> f: +41 44 455 74 01
> daa [at] open
>
> http://www.open.ch
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk2tsBMACgkQxIzmH53Qg6HBtgD+Jxvl+v+YGAuwFgnq0b9fmsjR
> Ve9Pa7yiAlaRO568asABAJTRmorB8vIggS/VqZ/JfUs255AZdMOHKmWEQDd9txPA
> =rX7B
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

---
If you can not measure it, you can not improve it - Lord Kelvin

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

mam at open

Apr 20, 2011, 1:20 AM

Post #11 of 13 (1001 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

Hi Luca,
our tests are trying to put as much stress as we can on nprobe from a
flows-per-second point of view, and since we don't have dedicated HW
generators we generate 1 packet flows, TCP, of the smallest size
possible. The flows/s (and pk/s as well, since flows are 1 pkts long
flows) are in these tests 100K/s. There are six virtual machines
generating this traffic, so 6 different source IPs. Each of them chooses
randomly a destination port Xi (i=1,....,6), then generates 60,000
packets incrementing each time deterministically the destination port by
one (Di, Di+1, Di+2, ...), then the loop repeats itself with every VM
incrementing deterministically Xi by one.
So, at the end, two nested loops on the src and dst ports. This means
actually low "entropy" (a lot of subsequent pkt headers will differ by
one bit only) but this is similar to what happens e.g. in a port
scanning. A "good" hash should distribute randomly also with 1 bit
variations, but I know this is difficult. What hash is nprobe using, BTW?
Here below, the probability of long lists that we expect with a
perfectly uniform hash distribution for that load, hash size of 2^23,
flows kept in the flow cache for 11 seconds (10 sec idle tout and 1 sec
scan cycle). Bucket sizes of 16 elements are clearly indicating an
uneven distribution of the hash.
Cheers,
Maurizio

K P(list>k)
0 1.00E+00
1 1.16E-01
2 7.54E-03
3 3.30E-04
4 1.08E-05
5 2.83E-07
6 6.19E-09
7 1.16E-10
8 1.90E-12
9 2.77E-14
10 3.63E-16
11 4.33E-18
12 4.73E-20
13 4.77E-22
14 4.47E-24
15 3.91E-26
16 3.20E-28
17 2.47E-30
18 1.80E-32
19 1.24E-34
20 8.15E-37

On 19.04.2011 18:07, Luca Deri wrote:
> Daniel
> it looks your traffic is not easy balance-able then. What kind of packets are you using?
>
> Luca
>
> On Apr 19, 2011, at 5:53 PM, Daniel Aschwanden wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hi Luca,
>>
>> On 04/19/2011 05:33 PM, Luca Deri wrote:
>>> Daniel
>>> if you have 100k concurrent flows, -w 256000 will do the job
>>>
>>> Luca
>>
>> Unfortunately not (-w 262144):
>>
>> 19/Apr/2011 17:40:39 [nprobe.c:1459] ---------------------------------
>> 19/Apr/2011 17:40:39 [nprobe.c:1460] Average traffic: [105.431 K pps][68
>> Mb/sec]
>> 19/Apr/2011 17:40:39 [nprobe.c:1465] Current traffic: [142.662 K pps][88
>> Mb/sec]
>> 19/Apr/2011 17:40:39 [nprobe.c:1471] Current flow export rate: [12653.5
>> flows/sec]
>> 19/Apr/2011 17:40:39 [nprobe.c:1474] Flow drops: [export queue too
>> long=0][too many flows=0]
>> 19/Apr/2011 17:40:39 [nprobe.c:1480] Flow Buckets:
>> [active=532231][allocated=532231][toBeExported=0][frags=0]
>> 19/Apr/2011 17:40:39 [nprobe.c:1516] Processed packets: 10332302 (max
>> bucket search: 14)
>> 19/Apr/2011 17:40:39 [nprobe.c:1519] Flow Collection: [collected pkts:
>> 0][processed flows: 0]
>> 19/Apr/2011 17:40:39 [nprobe.c:222] Packet stats: 10332424/0 pkts
>> rcvd/dropped [0.0%] [Last 285324/0 pkts rcvd/dropped]
>> 19/Apr/2011 17:40:42 [nprobe.c:1459] ---------------------------------
>> 19/Apr/2011 17:40:42 [nprobe.c:1460] Average traffic: [105.521 K pps][68
>> Mb/sec]
>> 19/Apr/2011 17:40:42 [nprobe.c:1465] Current traffic: [108.445 K pps][67
>> Mb/sec]
>> 19/Apr/2011 17:40:42 [nprobe.c:1471] Current flow export rate: [29935.3
>> flows/sec]
>> 19/Apr/2011 17:40:42 [nprobe.c:1474] Flow drops: [export queue too
>> long=0][too many flows=0]
>> 19/Apr/2011 17:40:42 [nprobe.c:1480] Flow Buckets:
>> [active=605659][allocated=606136][toBeExported=477][frags=0]
>> 19/Apr/2011 17:40:42 [nprobe.c:1516] Processed packets: 10657626 (max
>> bucket search: 16)
>> 19/Apr/2011 17:40:42 [nprobe.c:1519] Flow Collection: [collected pkts:
>> 0][processed flows: 0]
>> 19/Apr/2011 17:40:42 [nprobe.c:222] Packet stats: 10657745/0 pkts
>> rcvd/dropped [0.0%] [Last 325321/0 pkts rcvd/dropped]
>>
>> I know in theory the probability of occurance of list size> 16 should
>> be quite small.
>>
>> I'm even more confused about that a obviously too big hash (2^23)
>> doesn't decrease the list size.
>>
>> Any suggestions?
>>
>> Thanks a lot!
>>
>> Cheers, Dani
>>
>> - --
>> daniel aschwanden
>> junior engineer
>>
>> open systems ag
>> raeffelstrasse 29
>> ch-8045 zurich
>> t: +41 44 455 74 00
>> f: +41 44 455 74 01
>> daa [at] open
>>
>> http://www.open.ch
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iF4EAREIAAYFAk2tsBMACgkQxIzmH53Qg6HBtgD+Jxvl+v+YGAuwFgnq0b9fmsjR
>> Ve9Pa7yiAlaRO568asABAJTRmorB8vIggS/VqZ/JfUs255AZdMOHKmWEQDd9txPA
>> =rX7B
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> ---
> If you can not measure it, you can not improve it - Lord Kelvin
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

--
Maurizio Molina
Product Manager

open systems ag
raeffelstrasse 29
ch-8045 zurich

t: +41 44 455 74 00
f: +41 44 455 74 01
mam [at] open
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

daa at open

Apr 28, 2011, 2:19 AM

Post #12 of 13 (965 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all, Hi Luca,

I have a further question regarding the memory management of nprobe:

How is the memory management handled?

I'm asking that question, because I'm experiencing the following:

Firstly, nprobe is started and it consumes only about one percent of
memory, because there isn't any severe traffic. Then I'm starting my
traffic generators which generates around 100k flows per second (as
Maurizio had outlined in the previous mail). This leads of course to a
bigger memory usage. However, if the traffic generation has finished and
there is no traffic again, the memory consumption stays as it was.

So my question: why does nprobe not freeing the unused memory?

I guess this memory growth is according to longer bucket lists, since
the hash size stays constant. As mentioned before, I'm also experiencing
very long lists (19-31 max. bucket search).

Furthermore, if I run the traffic generation for a very long time,
nprobes memory consumption is monotonically growing at a low pace till
it runs out of memory.

Some details of the configuration:
nprobe v.6.3.0 ($Revision: 1947 $) for i686-pc-linux-gnu
- -t=10
- -d=10
- -l=1
- -s=2
- -V=5
- -w=8388608
- -M=8000000
- -e=0

Thanks for your comments and explanation of that.

Cheers,
Dani

On 04/20/2011 10:20 AM, Maurizio Molina wrote:
> Hi Luca,
> our tests are trying to put as much stress as we can on nprobe from a
> flows-per-second point of view, and since we don't have dedicated HW
> generators we generate 1 packet flows, TCP, of the smallest size
> possible. The flows/s (and pk/s as well, since flows are 1 pkts long
> flows) are in these tests 100K/s. There are six virtual machines
> generating this traffic, so 6 different source IPs. Each of them chooses
> randomly a destination port Xi (i=1,....,6), then generates 60,000
> packets incrementing each time deterministically the destination port by
> one (Di, Di+1, Di+2, ...), then the loop repeats itself with every VM
> incrementing deterministically Xi by one.
> So, at the end, two nested loops on the src and dst ports. This means
> actually low "entropy" (a lot of subsequent pkt headers will differ by
> one bit only) but this is similar to what happens e.g. in a port
> scanning. A "good" hash should distribute randomly also with 1 bit
> variations, but I know this is difficult. What hash is nprobe using, BTW?
> Here below, the probability of long lists that we expect with a
> perfectly uniform hash distribution for that load, hash size of 2^23,
> flows kept in the flow cache for 11 seconds (10 sec idle tout and 1 sec
> scan cycle). Bucket sizes of 16 elements are clearly indicating an
> uneven distribution of the hash.
> Cheers,
> Maurizio
>
> K P(list>k)
> 0 1.00E+00
> 1 1.16E-01
> 2 7.54E-03
> 3 3.30E-04
> 4 1.08E-05
> 5 2.83E-07
> 6 6.19E-09
> 7 1.16E-10
> 8 1.90E-12
> 9 2.77E-14
> 10 3.63E-16
> 11 4.33E-18
> 12 4.73E-20
> 13 4.77E-22
> 14 4.47E-24
> 15 3.91E-26
> 16 3.20E-28
> 17 2.47E-30
> 18 1.80E-32
> 19 1.24E-34
> 20 8.15E-37
>
>
>
> On 19.04.2011 18:07, Luca Deri wrote:
>> Daniel
>> it looks your traffic is not easy balance-able then. What kind of
>> packets are you using?
>>
>> Luca
>>
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

- --
daniel aschwanden
junior engineer

open systems ag
raeffelstrasse 29
ch-8045 zurich
t: +41 44 455 74 96
f: +41 44 455 74 01
daa [at] open

http://www.open.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk25MSEACgkQxIzmH53Qg6EQSQEAghNTyKmejaAjZdhiI/25xrFV
Ar3F3tUuRcgtW0OTSUgA/2c/npNbNQa8SASgW3lsHEnSJIZGER66QhZEh06o9wtx
=Iy93
-----END PGP SIGNATURE-----
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

deri at ntop

Apr 29, 2011, 10:10 AM

Post #13 of 13 (966 views)
Permalink

Re: nProbe hash size and allocation [In reply to]

Daniel
thanks for your comments. The first answer to your question is to read the code :-)

We had some memory leaks in the past but I;m not aware of any of them recently. Valgrind confirms that. The memory is allocated and released during flow life time thus at the end of its life the memory is freed. Unix generally reports the top memory usage, so sometimes you read the top memory being allocated. Concerning hashing I am taking advantage of your suggestions and currently working at that.

Finally, I have made quite some changes in nprobe 6.4.x with respect to the version you use. You can read them here http://www.ntop.org/blog/nprobe/tuning-nprobe-6-4-scalability-and-performance/. I suggest you to update whenever possible (note that the hashing function is under test thus it is not included in the code being released).

Cheers Luca

On Apr 28, 2011, at 11:19 AM, Daniel Aschwanden wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all, Hi Luca,
>
> I have a further question regarding the memory management of nprobe:
>
> How is the memory management handled?
>
> I'm asking that question, because I'm experiencing the following:
>
> Firstly, nprobe is started and it consumes only about one percent of
> memory, because there isn't any severe traffic. Then I'm starting my
> traffic generators which generates around 100k flows per second (as
> Maurizio had outlined in the previous mail). This leads of course to a
> bigger memory usage. However, if the traffic generation has finished and
> there is no traffic again, the memory consumption stays as it was.
>
> So my question: why does nprobe not freeing the unused memory?
>
> I guess this memory growth is according to longer bucket lists, since
> the hash size stays constant. As mentioned before, I'm also experiencing
> very long lists (19-31 max. bucket search).
>
> Furthermore, if I run the traffic generation for a very long time,
> nprobes memory consumption is monotonically growing at a low pace till
> it runs out of memory.
>
> Some details of the configuration:
> nprobe v.6.3.0 ($Revision: 1947 $) for i686-pc-linux-gnu
> - -t=10
> - -d=10
> - -l=1
> - -s=2
> - -V=5
> - -w=8388608
> - -M=8000000
> - -e=0
>
> Thanks for your comments and explanation of that.
>
> Cheers,
> Dani
>
>
> On 04/20/2011 10:20 AM, Maurizio Molina wrote:
>> Hi Luca,
>> our tests are trying to put as much stress as we can on nprobe from a
>> flows-per-second point of view, and since we don't have dedicated HW
>> generators we generate 1 packet flows, TCP, of the smallest size
>> possible. The flows/s (and pk/s as well, since flows are 1 pkts long
>> flows) are in these tests 100K/s. There are six virtual machines
>> generating this traffic, so 6 different source IPs. Each of them chooses
>> randomly a destination port Xi (i=1,....,6), then generates 60,000
>> packets incrementing each time deterministically the destination port by
>> one (Di, Di+1, Di+2, ...), then the loop repeats itself with every VM
>> incrementing deterministically Xi by one.
>> So, at the end, two nested loops on the src and dst ports. This means
>> actually low "entropy" (a lot of subsequent pkt headers will differ by
>> one bit only) but this is similar to what happens e.g. in a port
>> scanning. A "good" hash should distribute randomly also with 1 bit
>> variations, but I know this is difficult. What hash is nprobe using, BTW?
>> Here below, the probability of long lists that we expect with a
>> perfectly uniform hash distribution for that load, hash size of 2^23,
>> flows kept in the flow cache for 11 seconds (10 sec idle tout and 1 sec
>> scan cycle). Bucket sizes of 16 elements are clearly indicating an
>> uneven distribution of the hash.
>> Cheers,
>> Maurizio
>>
>> K P(list>k)
>> 0 1.00E+00
>> 1 1.16E-01
>> 2 7.54E-03
>> 3 3.30E-04
>> 4 1.08E-05
>> 5 2.83E-07
>> 6 6.19E-09
>> 7 1.16E-10
>> 8 1.90E-12
>> 9 2.77E-14
>> 10 3.63E-16
>> 11 4.33E-18
>> 12 4.73E-20
>> 13 4.77E-22
>> 14 4.47E-24
>> 15 3.91E-26
>> 16 3.20E-28
>> 17 2.47E-30
>> 18 1.80E-32
>> 19 1.24E-34
>> 20 8.15E-37
>>
>>
>>
>> On 19.04.2011 18:07, Luca Deri wrote:
>>> Daniel
>>> it looks your traffic is not easy balance-able then. What kind of
>>> packets are you using?
>>>
>>> Luca
>>>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> - --
> daniel aschwanden
> junior engineer
>
> open systems ag
> raeffelstrasse 29
> ch-8045 zurich
> t: +41 44 455 74 96
> f: +41 44 455 74 01
> daa [at] open
>
> http://www.open.ch
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk25MSEACgkQxIzmH53Qg6EQSQEAghNTyKmejaAjZdhiI/25xrFV
> Ar3F3tUuRcgtW0OTSUgA/2c/npNbNQa8SASgW3lsHEnSJIZGER66QhZEh06o9wtx
> =Iy93
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

---
We can't solve problems by using the same kind of thinking we used when we created them - Albert Einstein

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads