new code uploaded - argus cygwin support

[Carter Bullard]

I think for the release, Argus no threads, clients threads, but .....,
if we have any problems with ra() using threads, then we'll shift
back to no threads.  ra() is the most important tool, if only because
all the ra* programs share all the code in ra(), so, ....,  it should
run without any problems.

Yes, I'm going through the return codes for all memory allocs, and
trying to figure out how to continue running.  I'll have that by Monday.
Also need to throttle syslog messages so we don't kill the system
saying the system is being killed ;o)

For ra* with threads, I need to research a little on thread scheduling.
The data producer (thread reading the remote sockets and files)
can know if the RecordSerializer is backing up, but I don't have any
way to explicitly give up the CPU to the Serializer so it can catch up.
I'm sure there is a way to give up the slice gracefully.  Maybe just
nanosleep().

The #1 task for argus-3.1 is to get the threads working.  Its the only
way we'll get above 10Gbps for a software Argus.   I'm thinking a
3.0Ghz "Octacore" Mac maybe able to do 40Gbps monitoring if
we can split the tasks just right.

Carter


On Sep 13, 2007, at 10:41 AM, Peter Van Epp wrote:

> On Thu, Sep 13, 2007 at 09:43:00AM -0400, Carter Bullard wrote:
>> WoW!!  Finally a day with computational sunshine  ;o)
>>
>> This is with .threads for the clients?
>>
>> I think I've fixed John's ratop segfault, but I need to check it
>> on other machines to be sure.  I'm still having a locking issue
>> with ratop() when it reads from a file, with .threads, as on
>> thread gets done reading the file, but other threads are still
>> working the records, and they get out of sync,  but I think this
>> is an easy one.
>>
> <snip>
>
> 	Still good this morning (at least memory wise):
>
> ps auxwwww | grep argus
> root     12857  6.6  9.8 390316 386012 ?       SL   Sep12  47:43  
> argus -J -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
> vanepp   18317  0.0  0.0   3132   832 pts/0    S+   07:34   0:00  
> grep argus
>
> vanepp    7018   0.9 -0.1    30872   2220  p1- S     7:40PM    
> 5:33.13 /usr/local/bin/ra3 -S 192.75.244.191:560 -n -D4 -w /var/log/ 
> argus/com_argus
> vanepp    7724   0.0 -0.0    27376    420  p2  S+    7:34AM    
> 0:00.00 grep ra3
>
> at present both are with no .threads. Are both now thought to be  
> good for
> threads? I'll add it to clients because it was there and I removed  
> it and
> wait to hear on argus (where it wasn't defined by default I don't  
> think).
> 	At some point we probably want to start checking for malloc failures
> since we probably want to crash in that case so that we don't  
> corrupt data.
> When I was looking at memory calls there are lots of places that  
> don't check
> for a malloc/calloc failure, but with threads it will be  
> complicated (unless
> we just crash without worrying about thread locks of course :-)). I  
> didn't
> look at argus to see if it is the same.
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>