radium fails (rc.50 from 2007-08-31)

[Carter Bullard]

I wouldn't worry about the "-R" option, most of its function has been  
integrated
into the basic flow modeler now.  It will drastically increase the  
amount of output
records you generate if you have a lot of single request response  
protocols,
like NFS or AFS, so, probably not a requirement.  I'll go through to  
make
sure I can eliminate it as an option.

OK, we're back to being stable on argus-3.0.0 and time to refocus on  
clients,
to get ready for the release, which is now 4 months behind my  
schedule :o(
We may have lost anyone that was interested, so let me get the  
clients squared
away and get back to using the data, rather than generating it ;o)

Thanks for all your help, and of course if there is any gotcha, be  
sure and send
it to the list!!!!!

Carter


On Sep 4, 2007, at 3:14 PM, Peter Van Epp wrote:

> On Tue, Sep 04, 2007 at 09:38:59AM -0400, Carter Bullard wrote:
>> Peter,
>> We should leave the threaded version for argus-3.1, and assume that
>> all testing should be on the non-threaded version from now on.  But
> <snip>
>
> 	That looks to be a fine idea :-). This copy of the current  
> argus-3.0.0
> without .threads but with -J has been running since yesterday in ~  
> 370K of
> ram (and load is back up to normal peak levels here today):
>
> ps auxwwww | grep argus
> root      9499  6.0  9.1 364200 360488 ?       SL   Sep03  54:03  
> argus -J -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
> vanepp   10801  0.0  0.0   3132   832 pts/1    S+   12:05   0:00  
> grep argus
>
> 	I may take my life in my hands and try the -R flag and see what  
> happens
> too :-). I'd say we seem to have fixed the issue (at least on PPC  
> which is
> what I'm on, testing on Intel would be good in case there is an  
> endian problem)
> with unlimited memory growth. It may be time to start again  
> comparing output
> from 3.0 with output from 2.0.6 on the same link to make sure they  
> are at
> least close to each other (they were in good shape last I tried but  
> there have
> been many changes since then :-)).
>
> Peter Van Epp / Operations and Technical Support
>