Stability problems.

[Carter Bullard]

Hey Peter,
   I've measured well above 25-30K pps using Redhat kernels,
so I'm interested in their numbers as well!

   Actually, Argus may not get toooo confused in your
scenario, as it deals with out of order packets pretty
well.

   Can you generate a DDOS simulator with your tools?

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com 

   

-----Original Message-----
From: owner-argus-info at lists.andrew.cmu.edu
[mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Peter Van
Epp
Sent: Thursday, June 07, 2001 11:45 AM
To: argus
Subject: Re: Stability problems.


	A possibly unrelated point: in the latest Usenix login: there is
a 
conference report from the Linux kernel developers conference (which one
would not expect to be biased against Linux :-)). The point of interest
is a 
discussion that the Linux 2.4 kernel hangs at around 24K PPS yet a BSD 
kernel doesn't hang until 200K PPS. They didn't specify a link speed
(possibly gig), but this flys in the face of measured experience here
(Linux does at least as well and usually better than FreeBSD), It is
also unclear (although one wouldn't expect it at a kernel developer's
conference) what board/drivers this was with. Some drivers exhibit this
behaviour (Realtec and the 3Com 3c905 driver) but there are better
drivers.
	More related to Chris's problem: I have a patch set which will
allow tcpreplay to simulate a full duplex link using two capture files
and two 
Enet cards. When last I tried it (some time ago) with a single IDE disk
it would do about 160 megs per sec (likely disk limited). The fly in the
ointment is that you would need to carefully adjust the capture files to
start 
identically in order to run the files at full speed (otherwise the reply
packets can come in before the packet that caused it goes out, which
would undoubtably confuse argus). Somewhere down my list of interesting
things to do is write a "dump file optimiser" that would deal with this
(i.e. reorder the packets in a tcpdump file so that the packet sequence
will be correct when played back at full speed) but it hasn't even been
started yet.
	Given this and a test bed you can effectively test the failing
case (since you know all the packets that should appear) and see where
(if anywhere) you are losing things and what you are losing.

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