Throughput testing.

[Peter Van Epp]

	You may  be correct. I asked about this on the NFR list (since NFR 
recommends OpenBSD on the PC as their platform of choice and claims to be able
to do 200 or so megs with a custom capture interface (not libpcap) on their
commercial version (a claim I hope to test later). One of their folks pointed 
out an 8K buffer size in the BPF code which can cause latency problems at 100. 
I tried boosting that to 64K on the OpenBSD machine earlier today but it didn't
seem to help any. The Etherexpress cards are about 5 megs faster than the 3com 
(and the 3com is known for finicky timing, it won't run in some of my machines)
so it may be the Etherexpresses. Suprisingly the cheap Allied Telesyn / Realtek
10/100 Ether cards are as fast as the Intel on tcpreplay (with the 3com lagging
by about 5 megs). They seemed to have a driver problem that caused panics at
high receive volume on 4.0 (although I haven't seen it on 4.1) which is why
I have been using the 3coms to test.

> 
> I would be surprised if it wasn't motherboard first,
> ethernet card second, and SCSI third for Argus-2.0.
> 
> Argus 1.8 and earlier should be SCSI sensitive first,
> motherboard second and ethernet card third, unless
> the ethernet card is really really really cheap.
> Just a gut feeling but I've been surprised before ;)
> 
> Argus-1.8.1 writes to disk from the same thread that
> is reading packets, opens the file, writes and closes,
> where Argus-2.0 has separate processes doing the trick
> and doesn't close the file until the name is gone.
> But then again Argus-2.0 has the added pipe processing
> and buffering to get the separation.
> 
> It will be an interesting comparison.
> 
> Do you want some help on tcpreplay?  You know I think
> it would be cool if Argus data drove the traffic
> generation rather than tcpdump data.

	Sure, I'm up for all the help I can get :-). It looks pretty straight
forward to do what I want, add multiple interfaces and two files then merge
the streams for time syncronization. I expect performance is going to be the
killer, in this case probably disk I/O but possibly bus bandwith as well.
The more options we have for input streams the better as far as I'm concerned.

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