[ARGUS] Argus on 64 bit architecture

Wed Apr 14 10:45:50 EDT 2004

How in [insert your deity's name here] name does anyone expect
life to function if you change the definition of timeval?
Bad, bad, bad......   But, not a show stopper.

Thanks, I'll add that to the list.

Carter

-----Original Message-----
From: Gilles.Gallot at idris.fr [mailto:Gilles.Gallot at idris.fr]
Sent: Wednesday, April 14, 2004 9:02 AM
To: carter at qosient.com
Cc: James.Gill at mci.com; 'Peter Van Epp'; argus-info at lists.andrew.cmu.edu
Subject: Re: [ARGUS] Argus on 64 bit architecture

Carter Bullard wrote:

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

No only,  the function gettimeofday uses  the structure timeval.
The size of that structure  is 16 bytes on the alpha or amd64 architecture
and with
the linux operating system.

In the argus_out include:
you can find the struct timeval  in
        ArgusTimeDesc
        ArgusAGRStruct
        ArgusMarStruct                            ( with linux: argtimeval =
timeval)

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