use of .debug and .devel as tags in root argus directory

[Carter Bullard]

Hey Neil,
   My rule of thumb on the debug level assignments
was one time routines, such as major initializations,
get a debug level of 1.  Level 2 gets process creation
and single structure allocations.  Level 3 gets record
output module activity, 4 gets interprocess
communication reports, and 5 and greater get per packet
reports.  Now I didn't follow that to the letter
but I got something that was useful at level 3 and 4
that was not too much information and I could solve
problems with it.  Level 5 and 6 not really unusable as
there were per packet reports, but it may solve some
real problems one day.

   OK, regarding byte reporting.  In 1.8 and 1.8.1,
we reported user data, so for TCP transactions, you
would not get counts for the ethernet, IP or TCP
header overhead.  In 2.0 I'm trying to offer both,
as the TCP records themselves have ack'd bytes, and
total bytes.  In the default output records, we're
reporting total bytes, so it will be larger than
the 1.x reports.

   The Man records definitely need some work.  Your
final record has bytes being reported as drops, and
that's probably due to the fact that I changed those
counters to long long's.

   I have fixed a bug in the arp record byte counts,
so if you see some problems there, I'm onto it.

Carter



-----Original Message-----
From: Neil Long [mailto:neil.long at computing-services.oxford.ac.uk]
Sent: Sunday, September 03, 2000 4:15 PM
To: carter at qosient.com
Cc: Neil Long
Subject: Re: use of .debug and .devel as tags in root argus directory


Hi Carter
Thanks for the info (any special -d levels worth setting?).

Here is some data for comparison between 1.8, 1.8.1 and 2.0.0 
which might help tracking down a problem with the byte counts.

Again this may just be a FreeBSD implementation problem with the
argus record format. Something amiss with 1.8.1 as well with racount 
and the byte numbers.  So I am afraid that I may have been chasing
vapours - I will do some real packet analysis tomorrow.
Hmm - a quick check on Solaris indicates I also have a problem with 
racount there as well. I need to look in to this properly.

I think I will stick with Solaris for a while.....

Neil