FOLLOWUP: oddities with ramon

[Carter Bullard]

Hey Harry,
   Sorry for the delayed response.  You're probably running into
the 32-bit counter overflow problem.  ramon() is an aggregator,
and because argus data is limited to 32 bit counters, if merging two
records would result in a counter overflow, the tool, will immediately
flush out the accumlated record and start aggregating again, so you
don't lose any data.

   Most people use perl() to handle this condition, and ragraph() is
the example we provide in the package to show how to deal with
it.  It maybe that having a simple routine that does just the aggregation
would be a good idea?

Carter


Harry Hoffman wrote:

> Hi All,
>
> First, thanks for the many good hints in trying to figure out why:
> ramon -M TopN 10 -nnnr argus.[date] was spitting out off of it's records.
>
> I've since moved over to a linux box for running argus and the same
> thing is again happening.
>
> I've checked /var/log/messages for any signs of memory trouble and none
> are present. I've also run top in another session and ramon will take
> anywhere from 103M to 207M while it's crunching numbers.
>
> I have found something interesting though... If I run ramon against my
> first netblock (I have two class Bs 192.168 and 172.16)
> ramon -nnnr argus.[date] - net 192.168
> then everything works as expected (this netblock sees considerably less
> traffic then the second netblock)
>
> However, running it against the second netblock is where things go
> hay-wire. But if I limit the scope in the second netblock then things
> again work
> ramon -nnnr argus.[date] - net 172.16.1
>
>
> Ideas?
>
> Thanks,
> Harry
>
>