argus-2.0.0 tuning

[Peter Van Epp]

> 
> 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?

	Yes should make a reasonable sensor. One thing I think we need is to
benchmark all kinds of things (memory and disk both raw and through the 
operating / file system), motherboard chipsets, Ethernet cards, operating 
systems so we can predict what will make a good sensor and know what the 
limits are (and where we need to concentrate) on performance.

> 
>   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.

	The way to find out is to set one up, then use tcpreplay to play back
a tcpdump file multiple times and time it in each configuration and see what
is fastest with a given configuration.

> 
>  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?
> 

	As above. I don't know of any numbers like this (and our milage may 
vary anyway). This will also depend on the implementation of MP and the hardware
to some extent. I expect some implementations (such as Irix on SGIs) to be 
much better at this than others. There can also be unexpected bottlenecks such
as the serial processing being single threaded on Irix 6.5 (about the last thing
that still was ...).


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

	You shut off the interrupts (at the driver/hardware level) and poll the 
card status register either regularly through your code or in a busy loop (poor
form on a multitasking OS :-)). This reduces interrupt latency and non 
deterministic issues at the cost of more overhead. It would usually be used in 
an imbedded type application that needed every bit of speed (and doesn't 
neccessarily care about overhead). Its likely not practical in a multitasking
OS such as Unix although the RT extensions in FreeBSD could possibly be used
to do this (you need to guarantee the card gets polled regularly, and I'd bet
the scheduling granularity isn't fine enough to do this in a general OS).
	You would probably be better to look at the "optimized TCP/IP stack
adapted from FreeBSD" in said to be in RTEMS (www.oarcorp.com) as a more likely
place to gain processing time. I expect it spends more time in the stack than
in the interrupts (and thus there is more to gain more easily in optimizing
the stack). As I think you suggested earlier the Linux zero copy kernels are
another good place to look. The kernel/user copy is very expensive. You really
want to start by profiling the code so you identify the hot spots and know
where an optimization will gain you performance (not that this is easy of 
course :-)).


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

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada