Argus 3.0.6 and dnaclusters

[Carter Bullard]

Hmmmm,
Well on line 3907 in ArgusSource.c, we come out of a series
of select() calls, and various workarounds, for various bugs, 
and if we don't have any packets, we set the global time and
continue.  We could put a nanosleep() there, to give up the
run queue for a little while.  I'd put it right before the getimeofday()
call on line 3908.  Maybe sleep for 50 uSeconds?

Try this patch:

==== //depot/argus/argus/argus/ArgusSource.c#104 - /Volumes/Users/carter/argus/argus/argus/ArgusSource.c ====
3907a3908,3910
>                                  struct timespec tsbuf = {0, 50000}, *ts = &tsbuf;
>                                  nanosleep(ts, NULL);
> 

To see if that doesn't do something?

Carter 

On Dec 13, 2012, at 5:37 PM, Chris Wakelin <c.d.wakelin at reading.ac.uk> wrote:

> Yes it's a bug in DNA. I can't remember seeing a commit that claimed to
> fix it; the last I saw, I think on the topic was the developer's reply to
> 
> http://listgateway.unipi.it/pipermail/ntop-misc/2012-September/003279.html
> 
> (and IPv6 is fine now BTW :-) )
> 
> As far as I remember, for some reason Bro IDS manages to use select()
> without hitting the problem, I think, perhaps by adding empty select()
> calls with a timeout:
> 
> From Bro's IOSource.cc:
> 
>>        if ( all_idle )
>>                {
>>                // Interesting: when all sources are dry, simply sleeping a
>>                // bit *without* watching for any fd becoming ready may
>>                // decrease CPU load. I guess that's because it allows
>>                // the kernel's packet buffers to fill. - Robin
>>                timeout.tv_sec = 0;
>>                timeout.tv_usec = 20; // SELECT_TIMEOUT;
>>                select(0, 0, 0, 0, &timeout);
>>                }
> 
> I had a go at doing that in ARGUS but it made no difference (perhaps I
> put it in the wrong place!).
> 
> I'm happy to try things out on the test server, now I've updated
> everything (I'm using tcpreplay of a 10GB pcap over a 1Gb link from
> another machine using Intel e1000e cards and the time-limited DNA demo
> licence, so I can only test for 5 mins at a time).
> 
> Best Wishes,
> Chris
> 
> On 13/12/12 22:11, Carter Bullard wrote:
>> If I remember, the 100% CPU was a bug in the DNA code itself?
>> Was there a resolution to that?
>> If you would be a guinea pig, we can play around with it?
>> 
>> Carter 
>> 
>> 
>> On Dec 13, 2012, at 4:30 PM, Chris Wakelin <c.d.wakelin at reading.ac.uk> wrote:
>> 
>>> I've just tried 3.0.7.2 with latest PF_RING svn (post v5.5.1) and DNA
>>> clusters on a test machine. It looks like we do still need the name
>>> change (added "dna" to the list of interfaces that includes "dag" and
>>> "napa") and it still uses 100% of CPU, but otherwise appears to work.
>>> 
>>> Best Wishes,
>>> Chris
> 
> -- 
> --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
> Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
> IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 8439
> Whiteknights, Reading, RG6 2AF, UK              Fax: +44 (0)118 975 3094
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121213/7dcada9f/attachment.bin>