argus-2.0.0 tuning

[Carter Bullard]

Hey Chris,
   The existing architecture for Argus is designed with
SMP boxes in mind.  Argus is interrupt driven (packets),
so having another processor to redistribute the interrupt
load will be very nice.  Argus constrains itself a lot
so that it won't be away from the packet input queue too
long.   The self scheduling strategies are what limit our
ArgusRecord throughput, and another processor would make
most of those self scheduling issues go away.

   With the FlowModeler dedicated to a single processor,
and all the other stuff hanging on the other processor, the
Multiplexor, and the Record Dispatcher(s) and the kernel,
the total amount of system record throughput will go up
dramatically, and packet loss will go down as well.

   Also, you need cycles to do the audit file management,
aggregation, compression and distribution of the audit data.
So having some extra cycles is always a good thing.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com


> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu
> [mailto:owner-argus-info at lists.andrew.cmu.edu]On Behalf Of 
> Chris Newton
> Sent: Wednesday, April 04, 2001 1:15 PM
> To: Argus (E-mail); Carter Bullard
> Subject: RE: argus-2.0.0 tuning
> 
> 
> >===== Original Message From <carter at qosient.com> =====
> >Hey Chris,
> >   Hmmm, my math must be off, but with all options on
> >the average record size may be near 228-256 bytes, and
> >of course if your capturing user data, then upwards of
> >400-500 bytes per record is a better number.
> 
>   Yes, you are very close.  I am calculating the average 
> record size each time 
> I process the logs... and I get about 241 bytes.
> 
> >   One of the CMU machines that we're using is in the
> >same performance range as yours.  240MB processes
> >are the norm, they are handling around 85K to 100K
> >simultaneous flows, and generating near max record
> >throughput at peak.  The tuning we've done has eliminated
> >the load exits that you are seeing, but the patches that
> >I am doing now should make this much more stable under
> >sustained load, which is the goal.
> 
>   Yes, this is an important goal.  I'd like to see Argus be 
> able to handle a 
> whallop from the network (many many thousands of tiny 
> packets), and still deal 
> with it (assuming the hardware can deliver it to argus, that is).
> 
> 
> >   Any chance you could test on a dual-processor machine?
> >That would eliminate your problems, after the tuning.
> 
>   I do have a dual processor P2 400 Mhz.  I understand the 
> basics of why you 
> want a dual processor machine, but maybe you could explain 
> some of the load 
> characteristics of Argus as to why a dualy is optimal.  I am 
> about to order 
> some hardware... so, I might change my puchasing plans. :)
> 
> Thanks,
> 
> Chris
> 
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 
> Chris Newton, Systems Analyst
> Computing Services, University of New Brunswick
> newton at unb.ca 506-447-3212(voice) 506-453-3590(fax)
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20010404/06a05df9/attachment.html>