argus memory use on Linux 2.2.18

[Peter Van Epp]

> 
> Hey Chris,
>    Great questions.  The CMU guys can elect to tell you
> specifics about the entire CMU community, but I wouldn't
> be surprised with a 4-8X estimate of the number of machines
> CMU supports, but I have no information. Remember CMU has a
> lot of customers on the outside, as they support a number of
> Web servers/ftp servers and so the supported number of IP
> addresses may be in the 100K+ range easy.
> 
>    Ok, that's 90K simultaneous flows, with about 200-400
> flows per second arrival rate, average over 60 sec period
> is about right.
> 
>    For your hypothetical situation, the real performance
> issues are packet throughput, and disk throughput.  Its
> more bandwidth and duration of flows that get you with
> argus, rather than total systems supported, etc.  So for
> estimates of load, I've pretty  much gone with 5
> simultaneous flows per user system, 20 peak, with the
> average duration around 0.4 secs for local transactions,
> and 0.8 for remote (now these are all averages).  Servers
> get around 20 average, and 100 simultaneous flows, peak,
> per server just as rough numbers.  These of course are 
> just rough numbers, so for your 5000 user machines, I'd
> expect anywhere from 25,000 to 100,000 max flows.  I'd
> be surprised to see 500Mbps from 5000 machines, but
> I'm always surprised ;o)
> 
>    I would recommend a dual processor PIII 800-900 MHz
> machine with 250-500 MB of memory.  The memory bandwidth
> and disk performance are big issues, so I'd definitely do
> 160Mbps SCSI, and the best chip set available (133MHz FSB).

	You also probably want to get one of the (expensive) motherboards 
that does 4 way memory interleave with fancy NEC Vchannel DIMMs or equivelent.
A look at standard DIMM specs (the post is back in the list archive) indicates
that you are looking at ~600 megabits/per sec maximum (assuming no refresh
so you will get less in practice) just from the DIMM cycle time. The NEC
Vchannel stuff gets that up to about 8 gigabites per second (which implies
processing in less than 8 memory cyles for a fully loaded Gig link for 
instance). As a side note I was chatting with some folks from the Intel who
say the max they have seen in their labs on a PC class machine is around
700 megs (attributed to OS issues) with their gig card. Testing this stuff
(even at 100) is somewhat exciting. My last run through indicated that FreeBSD
has problems at full tilt boogie 100 (using Anzen's tcpreplay to generate
traffic and a wire speed router as an rmon device to make sure the packets
actually make the wire). The Ethernet device driver (rather than the bpf code
or argus) appeared to be where the loss occurred. Both Linux and a Sun quad
processor E450 were able to keep up to full 100. I haven't yet gotten back to
doing more testing (I have interest because CA*net3 is currently OC48 on its
way to OC192, and my link to it will go to at least Gig when we arrange for 
some fibre within the next year or so).
	Early testing with Iozone and bonnie disk benchmarks indicate that 
the 7200 RPM UDMA66 IDE drives can at least keep up with and perhaps beat
SCSI drives (the Solaris box had 10,000 RPM 36 gig SCSI drives and the bench
mark results were marginally slower than the IDE numbers but that needs a lot
more poking at). I'd like to get to the point where I can source a fdx 100
stream from tcpreplay from (probably dual) IDE disks so that I can do things
like aggregate in a Gig switch to provide higher loads for testing but so
far other than modify tcpreplay to be able to source an FDX stream I'm not
there yet. The primary need is a for a packet/time editor that will insure
the in order arrival of reply packets (i.e. so a reply packet doesn't appear
on one side of the link before the packet that caused it appears on the other
side of the link) which is a much bigger job than getting tcpreplay to do 
FDX (although performance there is still an unknown as well, I can do full
speed 100 from a PC with IDE disk, but can I do 200 megs, thats the next
step because its relatively speaking easy to do ...).
	See also the post from someone with an E450 successfully processing
200 to 300 megs with argus on a Gig link in the last month or three. So it
looks to me like the first place to work is on the hardware (and something
better than PC class machines may be in order) and once we have beaten that 
bottleneck then software performance will become an issue but it doesn't 
necessarily seem to be the issue yet.

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