[ARGUS] Argus on 64 bit architecture

[Peter Van Epp]

On Wed, Apr 07, 2004 at 04:41:10PM -0700, Mike Iglesias wrote:
> We currently have argus running on a dual 1ghz P3 system.  We're going
> to upgrade that to a dual 1.8ghz AMD Opteron system.  The old system
> is running argus 2.0.6 beta stuff.
> 
> The new system was installed with Redhat Enterprise Linux compiled
> for AMD 64 bit architecture.  I built the latest argus 2.0.6
> stuff from ftp.qosient.com, and copied over an argus data file from
> the old system.  When I ran "ra" on the old file, it displayed one
> line of output from the file:
> 
> 29 Mar 04 06:47:12           man xxx.xxx.xxx.xxx  v2.0                   1 0  0        0         0            0           STA
> 
> ra on the file on the old system produced a lot of lines of output.
>
<snip>

	At this you are better off than the fellow from MCI(?) that is on 
FreeBSD on a Sparc in that time_t doesn't look to have been converted to a 
long :-). In a very unscientific test I did on Macs (with a very small data
file and ra), a dual G5 showed very little difference in 32 bit and 64 bit
modes (I was trying to see how much difference 64 bit mode made for the 2.0.6
release candidate because as it stands it doesn't compile on G4 Macs). The 
current plan is to compile for OS 10 in 32 bit mode and rework configure to 
support 64 bit mode in the next development release. Carter also commented
earlier that cleaning up the code for 64 bit mode would be a 2.0.7 project ...
	I'd suggest running in 64 bit mode for a while and see if it works
without problem, and try and get some sense of performance and then convert 
back to 32 bit mode and see what difference it makes. You may find that 
hardware (memory bandwith, DMA and bus speeds) are the limiting factor rather
than CPU instruction length but I have no evidence to back that :-) If you
have the luxury of 2 machines a 64 bit and a 32 bit looking at the same data
stream would be the best test of all. So far my clear channel gig link to C4
does from 10 to 50 megabits per second, so speed problems here haven't 
materialized yet, so I haven't done anything speed related in quite some time.

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