argus memory use on Linux 2.2.18

[Chris Newton]

Thanks Peter.  We are doing the CA*net3 thing as well... we are currently 
running that link at 622Mbit (I believe), and heading for 1.2 Gb (again, I 
think those are the numbers I last heard).

Chris

>===== Original Message From Peter Van Epp <vanepp at sfu.ca> =====
>>
>> 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

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

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