new code uploaded - argus cygwin support

[Peter Van Epp]

On Thu, Sep 13, 2007 at 10:59:10AM -0400, Carter Bullard wrote:
> 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
> 

	I suspect at 40G you are likely in to "argus in a fpga" territory
:-) or at least a fpga based mux that decides (somehow :-)) to split the
traffic in to multiple streams directed out multiple gig or 10 gig ports
to a cluster of CPUs that do the rest of the processing. The major problem
is likely to be that there isn't a lot of memory in the fpgas for remembering
where the flows should be going. 

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada