Subject: Re: [ARGUS] A concrete packet loss example

Hey Peter,
   Any sense of pkts/sec?
Carter

> From: Peter Van Epp <vanepp <at> sfu.ca>
> Date: Fri, 29 Oct 2004 15:58:04 -0700
> To: <argus-info <at> lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] A concrete packet loss example 
> 
> Success looks to have plagued our efforts. On a SUSE 2.6.5-7.108 kernel
> with the ring buffer bpf code from www.ntop.org running on the dual athelon
> box described earlier with SysKonnect cards (which by the way need:
> 
> /etc/modprobe.conf
> 
> options sk98lin Speed_A=1000,1000 AutoNeg_A=Off,Off DupCap_A=Full,Full
> 
> to like an optical tap) we managed to get argus to report 13,850,389,170 bytes
> for a ~13 gigabyte at ~900 meg per second transfer across the Westgrid network
> with no reported loss on either the interfaces or the ring buffer bpf report.
> Highly recommended!. We are running around 64Megabytes in the kernel ring
> buffer and a 30 second reporting interval on argus (the default lost some
> data).
> Hopefully no one wants to know how, because the fellow who did the
> kernel for me leaves on vacation for a month tonite so you'll have to wait
> .
> 
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
> 

Subject: Re: [ARGUS] A concrete packet loss example

	High ? It was a 2 minite run of netperf with a 9K mtu with pretty
much only an ssh to the remote machine to start the netperf going sharing the
network with it. The ring code is set for a 128 byte slice and not to forward
the packets in to the TCP stack so it was presumably tossing most of the data
away after the driver had fetched it from the cards and mmapping the resulting
128 byte samples directly to the modified libpcap library avoiding the copy 
entirely (at least as I understand what the ring code is doing). Here is 
the transaction in question with start and end times displayed so by counting
packets and times we should be able to come up with a packet rate:

29,Oct,04,15:37:35,0.692388,29,Oct,04,15:38:05,0.692380,,6,aaa.bb.cc.dd,43116,->,aaa.bb.cc.eee,37454,372141,188069,3323153814,12439646,CON
29,Oct,04,15:37:35,0.687393,29,Oct,04,15:37:35,0.818177,,6,aaa.bb.cc.dd,43115,->,aaa.bb.cc.eee,12865,5,4,854,784,CON
29,Oct,04,15:38:05,0.692399,29,Oct,04,15:38:35,0.692384,,6,aaa.bb.cc.dd,43116,->,aaa.bb.cc.eee,37454,396986,200009,3533320000,13214202,CON
29,Oct,04,15:38:35,0.692435,29,Oct,04,15:39:05,0.692349,,6,aaa.bb.cc.dd,43116,->,aaa.bb.cc.eee,37454,391813,197857,3491121734,13074438,CON
29,Oct,04,15:39:05,0.692469,29,Oct,04,15:39:35,0.692451,,6,aaa.bb.cc.dd,43116,->,aaa.bb.cc.eee,37454,393189,198259,3501958974,13102734,CON
29,Oct,04,15:39:35,0.701901,29,Oct,04,15:39:35,0.703863,,6,aaa.bb.cc.dd,43115,->,aaa.bb.cc.eee,12865,2,2,132,388,FIN
29,Oct,04,15:39:35,0.692500,29,Oct,04,15:39:35,0.701993,,6,aaa.bb.cc.dd,43116,->,aaa.bb.cc.eee,37454,94,53,834648,3498,FIN

	The tests in the ring code paper indicate that this is the best case
senario (essentially no loss to wire speed with jumbo frames). Smaller packet
sizes still incur loss although its not clear that would be true on my hardware,
since the work in the paper was done on a less powerful machine and I haven't
so far tried it. 
	I also just got my new 4 port regenerator taps so I can put both argus
and my gig sniffer on this link and see if the stuff argus is reporting (a 
machine with multiple encapsulation types is one thing I want to see, many 
instances of retransmissions is another, although they may really be there)
are in fact correct. With my current single tap setup I can have argus or the 
sniffer, but not both (netoptics to the rescue ).

Subject: [ARGUS] Maybe SUSE linux kernel and bits

	Mike asked if I would put up a tarball of the Linux kernel I'm running
so I have done so (and expect some more people may be interested). At
newfraser.sfu.ca in  /pub/unix/argus you will find:

-rw-r--r--   1 vanepp   users      12800 Nov  3 13:29 etc_modprobe.conf
-rw-r--r--   1 vanepp   users     509570 Nov  3 13:19 libpcap-0.8.1.tar.gz
-rw-r--r--   1 vanepp   users    47993834 Nov  3 13:22 linux-2.6.5-7.108.tar.gz
-rw-r--r--   1 vanepp   users       9176 Nov  3 13:28 pcap-int.h
-rw-r--r--   1 vanepp   users      64482 Nov  3 13:28 pcap-linux.c

	This in theory (but perhaps not in practice if there are more kernel
bits that need including ) is the linux2.6.5-7.108 kernel with the 
ring buffer code patched in, the appropriately modified libpcap (which needs
to be configured/compiled/installed in the argus directory and then have 
/usr/local/include/pcap-bpf.h copied into /usr/local/include/net/bpf.h (or
configure fixed to deal with the new .h file, I was lazy ). In 
etc_modprobe.conf (which is really /etc/modprobe.conf) are the configure 
options (set the SysKonnect cards in to Manual FDX for the tap and boost the 
ring buffers to 65 megs) that I think should get picked up on boot (otherwise 
you may need to run modprobe somehow, but I don't know how ). The 2 pcap 
files are the ring code that is already in the libpcap-0.8.1.tar.gz file just 
so you can see what changed. This works with argus-2.0.6.fixes.1 as normal 
(the advanced may wish to channel bond the 2 cards together with the Linix 
channel bonding code, but I haven't done that yet). Good luck! 
	You can ask, but the fellow who knows all is gone for a month so you 
may not get an answer  If more bits are needed I do have the machine this 
came from whose /usr/src directory looks like this:

sniffer:/usr/src # ls -l 
total 211547

[ARGUS] why have multiple start / end time values ?

Hi.
Unless I'm mistaken (it has happened frequently),
there will be multiple timeval structures built into the code.

Should there be just one shared by all modules ?

Re: [ARGUS] why have multiple start / end time values ?

Hey Mike,
   Not sure what the issue is here?
Carter

> From: <slif <at> bellsouth.net>
> Date: Fri, 5 Nov 2004 10:06:18 -0500
> To: <argus-info <at> lists.andrew.cmu.edu>
> Subject: [ARGUS] why have multiple start / end time values ?
> 
> Hi.
> Unless I'm mistaken (it has happened frequently),
> there will be multiple timeval structures built into the code.
> 
> Should there be just one shared by all modules ?
> 

[ARGUS] one NULL case patch

I need to get these patches out quicker,
so that I can remember the conditions that
caused the problem.  Sorry about that.

The core was real enough.  Simply moving the
initial condition into the while expression
avoids the problem case.

I hope this one will be incorporated into,
or made irrelevant by,
tne next release of argus.

Best Regards,
-Mike Slifcak

Re: Re: [ARGUS] why have multiple start / end time values ?

I'm not sure, either. Just noticed that ArgusSource.h
either defines what appears to be single instances
of variables, or external references to those single
instances.

These two variables are the only ones _not_ prefixed
with "extern".

So, I guess this is more a question as to why there
are multiple instances of ArgusStartTime and ArgusEndTime.

With the patch applied, the server seems to work no
differently, but I have no exhaustive test to either
prove nor disprove the necessity of the patch.

> 
> From: Carter Bullard <carter <at> qosient.com>
> Date: 2004/11/05 Fri AM 10:10:47 EST
> To: <slif <at> bellsouth.net>, 
> 	Argus <argus-info <at> lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] why have multiple start / end time values ?
> 
> Hey Mike,
>    Not sure what the issue is here?
> Carter
> 
> > From: <slif <at> bellsouth.net>
> > Date: Fri, 5 Nov 2004 10:06:18 -0500
> > To: <argus-info <at> lists.andrew.cmu.edu>
> > Subject: [ARGUS] why have multiple start / end time values ?

Re: [ARGUS] why have multiple start / end time values ?

Hmmmmmmmmmm, well more than likely if there is a problem,
the compiler is silently correcting it for us.  But, that
is more troubling that comforting.  I'll go through the
globals to make sure there isn't some multiple declaration
possibilities.

Carter

> From: <slif <at> bellsouth.net>
> Date: Fri, 5 Nov 2004 10:24:58 -0500
> To: Carter Bullard <carter <at> qosient.com>, Argus
> <argus-info <at> lists.andrew.cmu.edu>
> Subject: Re: Re: [ARGUS] why have multiple start / end time values ?
> 
> I'm not sure, either. Just noticed that ArgusSource.h
> either defines what appears to be single instances
> of variables, or external references to those single
> instances.
> 
> These two variables are the only ones _not_ prefixed
> with "extern".
> 
> So, I guess this is more a question as to why there
> are multiple instances of ArgusStartTime and ArgusEndTime.
> 
> With the patch applied, the server seems to work no
> differently, but I have no exhaustive test to either
> prove nor disprove the necessity of the patch.
> 
> 

Re: Re: [ARGUS] why have multiple start / end time values ?

These files include the header,
but only ArgusSource.c defines ArgusSource,
which differentiates  definition from declaration.

  File           Line
1 ArgusAuth.c    75 #include <ArgusSource.h>
2 ArgusModeler.c 60 #include <ArgusSource.h>
3 ArgusOutput.c  57 #include <ArgusSource.h>
4 ArgusSource.c  58 #include <ArgusSource.h>
5 Argus_icmp.c   28 #include <ArgusSource.h>
6 Argus_mac.c    28 #include <ArgusSource.h>
7 argus.c        57 #include <ArgusSource.h>

But only ArgusModeler.c, ArgusSource.c, and argus.c
refer to ArgusStartTime and ArgusEndTime.

> 
> From: Carter Bullard <carter <at> qosient.com>
> Date: 2004/11/05 Fri AM 10:30:29 EST
> To: <slif <at> bellsouth.net>,  Argus <argus-info <at> lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] why have multiple start / end time values ?
> 
> Hmmmmmmmmmm, well more than likely if there is a problem,
> the compiler is silently correcting it for us.  But, that
> is more troubling that comforting.  I'll go through the
> globals to make sure there isn't some multiple declaration
> possibilities.
> 
> Carter

[ARGUS] fix select case: ensure read mask cleared first

the bit field arguments presented to select() must be freshly set
before any bits representing open file descriptors are set.

This patch fixes one case where the read mask was not cleared
before FD bits were set.

I've seen instances where the server would shut down completely
if the select errors out.  The server would log "client done",
and the "ra" client would print a "man" record whose last
field was "SHT".

The server is much more robust when this patch is applied.