RE: argus-2.0.0 tuning
Chris Newton <newton <at> unb.ca>
2001-04-05 00:49:59 GMT
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> =====
> 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.
>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
>> -----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. :)
>> 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)