Argus tweaking and design considerations

[Peter Van Epp]

<snip>
> >	The first step in this is to do what I started out to do and
> >characterize what load a given CPU/motherboard chipset/interface 
> card/operating
> >system configuration will handle with argus which tells us were we are
> >compared to where we want to be (and what the bottlenecks are to getting 
> there).
> 
> 
> 
>   Grat idea Peter.  I'd be very interested in working on a project related to 
> this if you/'a team' start down this road.  I might even (if we get our 
> project funded), eventually have man power to throw at such a thing.
> 
> 
> Chris
> 
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 
> Chris Newton, Systems Analyst
> Computing Services, University of New Brunswick
> newton at unb.ca 506-447-3212(voice) 506-453-3590(fax)
> 

	The bottom one is a game any number can play :-) Anzen's tcpreplay
package (and some mods I have to make it do full duplex which of course
aren't finished yet) and a generic PC with a pair of Intel or 3C905B cards
and cheap 7200 RPM UDMA 66 IDE disks (probably 2 for fdx)  will provide a 100 
(at least hdx, not sure about fdx yet) traffic source from tcpdump input to 
give you a known and reproducable input traffic source. Then all you need is a 
machine you want to test and time (it this last one I'm having trouble 
with :-)). 10 of them and a 100baseT switch with a wire speed Gig uplink port
gives you a GIG testbed. Then you publish the complete configuration and the 
numbers. The idea is given the speed of the link you want to sniff you can pick
a machine that should be able to keep up to full speed.

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