argus-2.0.0 tuning

[Chris Newton]

Ahh!  Ok. :)  A dualy it is then...

  Dell PowerEdge 300SC
  Dual 800 Mhz PIII processors
  Intel EtherExpress Pro 100
  64 MB PC133 Ram
  20 GB 7200 RPM IDE disk

  $1898 Canadian... or, roughly $1200-$1300 US.

  then, throw in an additional 512 MB of ECC ram at $140 CDN a stick...
  and an additional EtherExpress Pro... for $55 CDN.

  That should be a good sensor, no?

  Also, do you think this will help?  I have seen some utilities around that 
will allow you to bind a process to a CPU, to stop it from bouncing from one 
CPU to another when the kernel scheduler feels like it.  It would help cache 
hits, and performance to bind one of the argus threads to one CPU, and the 
other 2 less important ones to the other CPU, would it not?  Then, they'd 
never end up on the same CPU, regardless of whats going on.

 Also, I have seen utilities for binding particular ethernet cards to a 
particular CPU... so, we could have 1 CPU servicing interrupts from the main 
monitoring card, and the lightweight argus processes on that CPU as well... 
and have the other CPU bound to the main argus process.  Comments?

 Also, what is polling mode on an ethernet card... which cards support it, it 
it faster, and how is it enabled? :)

Sorry for all the questions people... but, thanks for any answers.

>===== Original Message From <carter at qosient.com> =====
>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)
>>
>>

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Chris Newton, Systems Analyst
Computing Services, University of New Brunswick
newton at unb.ca 506-447-3212(voice) 506-453-3590(fax)