racount

[Carter Bullard]

Hey Neil,
   Good to see you!  So, great embarrassment on my
part!  I called myself a programmer once long ago,
but no more!  Hopefully,  I'll have development machines
in next week so I can fix this problem.

   Great opportunity to talk about racount() and how
it can be improved.  Your mods break out the counts
by source and destination, this looks good.  I used racount()
primarily as a sanity check for debugging new versions of argus,
so I didn't need much from it.  Are there other things
that we could add to racount.c to make it more useful?

Carter

-----Original Message-----
From: Neil Long [mailto:neil.long at computing-services.oxford.ac.uk]
Sent: Monday, July 10, 2000 12:19 PM
To: carter at qosient.com
Subject: Re: racount


Hangs head in shame ..... 'twas 1.8 with mods - there was also a cherry tree
I wish to add to the plea bargaining...

However ;-)

../racount.181 -nr argus.07.06.11:00.gz
racount.181: totrcds    101282  rcds    101269  pkts            0
bytes  173961940


../racount.mods -nr argus.07.06.11:00.gz
racount: totrcds        101282  rcds    101269  pkts       173961940    src
bytes         2710310111    dst bytes         2652461504    total bytes
5362771615

This on Solaris so the printf still needs changing - the point I was trying
to raise was that as argus is applied to larger and larger netflows it may
become more of a problem. Peter's comment was useful in so far as Perl tries
to 'do the right thing'. I would guess that the most common argus platforms
will be the 32-bit *nix PCs although the wealthy few may have the odd DEC
Alphas to use as crunch tools.

Cheers
Neil




>Hey Neil,
>   Definitely seems like an overflow problem, but the racount() in
>argus-1.8.1, however, has its counters defined as long long, so
>this shouldn't be a problem.  Are you using 1.8.1 or 1.8 or the 1.7
>version of racount()?
>
>Carter
>
>-----Original Message-----
>From: owner-argus at lists.andrew.cmu.edu
>[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Peter Van Epp
>Sent: Thursday, July 06, 2000 10:05 PM
>To: argus at lists.andrew.cmu.edu
>Subject: Re: racount
>
>
>> i.e. the total bytes for the net is larger than the total for all nets
>>
>> I increased the format number from 9 to 12 in racount.c just to be sure
>> there is not a simple format error. The data types are unisigned long.
>>
>> Just to confirm this I simply added fields to output the total_src_bytes,
>> total_dst_bytes before the grand total ---
>>
>> ../racount -nr argus.07.06.11:00.gz
>> racount: totrcds        101282  rcds    101269  pkts       173961940
>> bytes    2710310111     bytes     2652461504    bytes     1067804319
>>
>> so that was 5.1G .....
>
> And if a long is 32 bits as is standard (although perhaps not on one
>of the 64 bit machines), you just overflowed, because 32 bits is around 4
>gigs.
>Which would leave you about a gig and a half after the over flow as you are
>seeing. I get around this by feeding the raw data in to perl which happily
>does
>multiprecision something under the covers and keeps on chugging up to the
>60 to 80 gigabyte level (I ran a test once to see if it had problems while
>I was chasing count descrepincies, I think I was up in the 100s of gigs
>without problem). That is perhaps one good reason for at least some thought
>of a perl interface from the data as Russell suggested (that and indexing
>arrays by almost anything ...) because it protects the unwary (such as me).
>One of the perl scripts that I posted long ago should do verify this for
>you if you feed it the raw ra data.
>
>>
>> Anyone got a LART I can borrow?
>
> If I knew what a LART was I might know if I have one  ...
>>
>> Cheers
>> Neil
>>
>
>Peter Van Epp / Operations and Technical Support
>Simon Fraser University, Burnaby, B.C. Canada
>
>
>