Timeranges

Peter Van Epp vanepp at sfu.ca
Wed Feb 11 01:13:18 EST 2004


On Wed, Feb 11, 2004 at 04:07:18PM +1100, Steve McInerney wrote:
> Perhaps the best option, from Carters perspective might be an actual 
> patch submission. ;-)

	I'm sure it would however time is lacking ...

> 
> But I would agree here Peter, being able to include flows that only 
> started and finished within a time range be appropriate. And thanks for 
> the reminder of the flows/timing!
> 
	The current semantics allow you to ask the question "why was traffic
so high in this time period" and thus you want flows that start and end out
of the time period because they contribute traffic in the selected time period.
	What I expect Andrew wants (because I do the same thing) is to account
for the traffic, which requires having a flow be part of one file or another
but not in both (which would cause double billing) and is slightly different 
than what the current time semantics are meant to produce. Both are probably
useful.

> 
> Perhaps, on further reflection, it might be appropriate to even go so 
> far as to ignore the split flows in this context. ie exclude that 
> portion of any flow which lies outside the time range; fractional flows 
> if that's clearer. I'm unsure how this would work at the detail level 
> with argus as it currently stands tho?
	
	That would be nice but is probably difficult since you would have to 
apportion the total traffic of the flow by the percentage of time of the 
complete flow that is in the time period (possibly on both ends if the flow
starts before the start time and continues past the end time). Given flow 
control and window sizes that won't be exact (because it assumes a constant 
data rate which it probably isn't) but may be close enough.


> To a large extent it would depend on how one wishes to use the end data. 
> Is it a raw size count?; Or the flows themselves that are of interest?
> 
> The intended end result should be looked at in more detail?
> 
> I can make an educated guess as to which Andrew would prefer, but it 
> would be more appropriate for him to enlarge IMHO.
> 
> 
> 
> Come to think of it - how DOES argus deal with split flows - for example 
> at startup? Does it simply ignore any already happening sessions?
> 

	Nope. An already started flow will have an indeterminate start flag 
(because argus didn't see the start of the flow) and account for the traffic
that argus sees once it starts. This usually isn't an issue because  the usual 
method is to leave argus running and steal the output file so argus has state
about the current flows when it creates a new output file. If you stop and 
start argus at file switches (which I do on 1.8) you potentially lose a little
bit of data during the restart but not very much. Similar things happen on 
stop. Ongoing flows will have indetermiate end flags (because argus didn't 
see them) and a possibly too small a data count, but accurate to the time of 
stop (and it will continue with some loss in a new argus record if you 
immediately start it again).

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




More information about the argus mailing list