[ARGUS] Argus on 64 bit architecture

[Carter Bullard]

Hey Guys,
   Sorry for the delayed response.  64-bit support in the clients
is indeed slated for 2.0.7 which should start soon.  While soon
has seemed to be measured in geologic time on this list for a while,
I do now have some cycles to spare for a short while.

   With regard to argus and 64-bit machines, here is my understanding
of the situation.  The only questionable value in existing argus data
that needs to be 'fixed' is in the MAR, management activity record.
The MAR record has 2 64-bit values in it, and they are currently
cast as (long long).  Now, these values are already 64-bit aligned
in the existing argus record, so if there is a problem, it should
only be in the type declared, and how 64-bit client programs try
to read the value.

   Internally there are a number of (long long) types declared, but
none should have alignment problems.  But there is one routine, the
one used to calculate the Syn/SynAck/Ack round trip times, that
returns a 64-bit value.  This routine is also declared as a (long long)
and probably needs to be changed.

   Any ideas on how to declare this type so we get it right
regardless of architecture?

   Hopefully the above is correct, and perhaps complete.  If there
is anything I'm missing, please don't be shy in tell me or the
list, that there is more to be considered.

Carter






-----Original Message-----
From: owner-argus-info at lists.andrew.cmu.edu
[mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Gill, James
Sent: Thursday, April 08, 2004 2:01 PM
To: Peter Van Epp
Cc: argus-info at lists.andrew.cmu.edu
Subject: Re: [ARGUS] Argus on 64 bit architecture


On Wed, 7 Apr 2004, Peter Van Epp wrote:

> 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

heh .. some days, that's all you need to say ;)

> FreeBSD on a Sparc in that time_t doesn't look to have been converted to a

i've fallen back to an i386 box with FreeBSD for the time being.
Everything seems to be fine :)  I'm just excited to have FreeBSD running
smoothly on a sparc.  I'm keeping the box in the rack to test new revs of
argus as they become available.


> 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.
>

--gill
        -----------------------------------------------------
        MCI/UUNET Network Security & Abuse * 1-800-900-0241,4
        -----------------------------------------------------
             v-net:  desk = 806-3834 ; group = 806-8805