another nit ...

[Carter Bullard]

Hey Peter,
   If you were dealing with binary argus records, then you
would just pick up the argus->argus_mar.init.now timeval
and you would be fine.  If you use raxml output, the
<ArgusDataStream "CurrentTime"> variable has your number.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com 

-----Original Message-----
From: owner-argus-info at lists.andrew.cmu.edu
[mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Peter Van
Epp
Sent: Friday, June 01, 2001 10:27 AM
To: argus
Subject: Re: another nit ...


	Yep, this helps (and the current behaviour makes sense). To do
what I want to do I only need to skip the first man record and take the
timestamp from the first data record so my start time reflects when the
data in the 
file started.

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

> 
> Hey Peter,
>    Here is the logic behind the time values in the initial management 
> record.  If we need to change it, lets do that.
> 
>    There are two time stamps in all argus records.
> For the initial management these times represent the
> argus startime and the current time.  The startime
> represents the time when argus started.  This is important for a 
> client to know if argus is restarting.  The "current time" is the time

> when the record was generated.  Clients can use this time for 
> synchronization purposes, or to calculate record propagation time.  
> That is, the time it takes for the ultimate receiver to finally get 
> the record. When argus is generating a file locally, the currentime
> will represent when the file was originally created.
> This is not necessarily relevant to the time that a
> particular argus file was created, because this initial
> argus record is not modified when you post process the file.
> 
>    If you sort an archive file, and generate a new
> sorted argus file, the first record in the new file will
> be the original initial management record, unchanged.
> Same goes for a when you use ra() to pick out that one
> record of interest, and store it in a file.  The initial management 
> record in the resulting file will be the original one.
> 
>    Now, this is an interesting issue, because when we aggregate 
> archive files, and actually create new argus records, the original 
> initial management record should probably be modified, since this is a

> brand new thing. And the argus ID in each aggregated record should 
> probably change, and the transaction ID's and sequence numbers
> also should probably change, which they don't do today.
> 
>    Not to open up a can of worms, but we should have some understood 
> "rules" as to what to do with the values, especially in archived 
> files.
> 
> 
> Hope this helps,
> 
> Carter
> 
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 18K
> New York, New York  10022
> 
> carter at qosient.com
> Phone +1 212 588-9133
> Fax   +1 212 588-9134
> http://qosient.com
> 
> 
> 
> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Peter Van 
> Epp
> Sent: Thursday, May 31, 2001 4:22 PM
> To: argus
> Subject: another nit ...
> 
> 
> 	I just noticed this nit: the date on the initial man looks to be
when 
> the argus started rather than when the file was ripped out from under 
> it (which was in fact 29 May 01 14:40). Assuming thats working as 
> designed I need to ignore the initial man line when figuring out when 
> a file started.
> 
> 22 May 01 20:57:53    man version=2.0     probeid=3848370891
> 
>                                         STA
> 29 May 01 14:39:59    udp ,,,
> 
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
> 
>