Problems with piping Argus output to rasplit

Nick Diel ndiel at engr.colostate.edu
Fri Mar 21 15:44:25 EDT 2008


Actually I was playing with it yesterday (even though I didn't exactly 
know what it did, wasn't sure if it was a sampling rate).

I didn't have much luck, I got to a point where either rasplit died or 
argus was sleeping way too much.  And I was using a timescale in the 
range of .1 (quite slow I know).  Now that I know exactly what the 
timescale does, I do some more testing.

Nick

Carter Bullard wrote:
> Hey Nick,
> One other thing you can use, is argus()'s realtime feature.  Although
> its a little tricky.  For simulation/testing purposes, you can have argus
> read packets at the rate they were received, or some multiple.  It maybe
> that you can get by with reading at 50-100x realtime, which may be
> slower than you're reading now, and that will give your rasplit(0 time
> to process the output records.  Try playing with the "-T timescale" 
> option
> to see if you can get good performance without hitting this threshold.
>
> Still a workaround, but maybe helpful.
>
> Carter
>
>
> On Mar 21, 2008, at 3:17 PM, Nick Diel wrote:
>
>> Carter,
>>
>> I will play around with nice.
>> I have been using intermediate files, am fortunate to have some disk 
>> space to work with.  I am just working on streamlining the operation 
>> as we start using Argus more and more.
>>
>> Nick
>>
>> Carter Bullard wrote:
>>> Hey Nick
>>> The problem is that argus closes the rasplit, because argus has 
>>> processed
>>> and generated more records than rasplit() has consumed, with the 
>>> records
>>> waiting to be read have exceeded the 100K record threshold.
>>>
>>> When argus is reading from the network it makes sense for argus to 
>>> close
>>> the reader, but when its reading from a file, it doesn't, since 
>>> we're not in
>>> a terrible hurry.  We should have some flow control so that it waits 
>>> a bit
>>> for rasplit to catch up.
>>>
>>> I can do something about this this weekend.  For a work around, maybe
>>> nice the argus priority down, and up the priority of the rasplit?  
>>> maybe write
>>> to intermediate files?  I know that probably is too much diskspace?
>>>
>>> Carter
>>>
>>> On Mar 21, 2008, at 1:55 PM, Nick Diel wrote:
>>>
>>>> I am having some problems piping Argus to rasplit.  I have a large 
>>>> set of pcaps I am turning into argus records.  I have about 700gigs 
>>>> of pcaps with a baseline of 10,000 packets/second and peaks at 
>>>> 17,000 packets/second.
>>>>
>>>> I am using the following command:
>>>> mergecap -a -w - pcap/*.pcap | argus -AJR -r - -w - | rasplit -r - 
>>>> -w argus. -a 4 -M size 1000m
>>>> ArgusWarning: argus[21937]: 20 Mar 08 11:36:52.428622 
>>>> ArgusWriteOutSocket(0xb7eaf008) max queue exceeded 100001
>>>> ArgusWarning: argus[21937]: 20 Mar 08 11:36:52.428879 
>>>> ArgusWriteOutSocket(0xb7eaf008) max queue exceeded 100001
>>>>
>>>> rasplit dies with in 30 seconds of starting (no messages to 
>>>> stderr), though it has created a 65mb files.  racount shows the 
>>>> 65mb file has no flows.  I can't tell if the Argus error message is 
>>>> before or after rasplit dies.
>>>>
>>>> The disk system is a fairly fast raid 5, 4 cpu cores, 2 gig of 
>>>> ram.  Barely any ram is in use when rasplit dies.
>>>>
>>>> Any thoughts?
>>>>
>>>> Nick
>>>>
>>>>
>>>
>>> Carter Bullard
>>> CEO/President
>>> QoSient, LLC
>>> 150 E. 57th Street Suite 12D
>>> New York, New York 10022
>>>
>>> +1 212 588-9133 Phone
>>> +1 212 588-9134 Fax
>>>
>>>
>>>
>>
>>
>
> Carter Bullard
> CEO/President
> QoSient, LLC
> 150 E. 57th Street Suite 12D
> New York, New York 10022
>
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax
>
>
>




More information about the argus mailing list