Calculating bits per second - the best way.

[Carter Bullard via Argus-info]

Hey David,
There are a few load (bps) values that are of interest.  Two specific concepts that argus data can support; average load and instantaneous load.   Because we provide the timestamps of the bounding packets (first and last) during a monitored interval, you can calculate an average over the status interval, or you can calculate an average over the active period (dur), which is a burst load estimate, or instantaneous load if the interval is small .  since the duration of the flow (ltime - stime) can be less than the observation period, if you do ((bytes * 8) / dur)  you will get a value (argus's load metric) that is higher than if you do ((bytes * 8) / status interval).  Both values are valid, but they are reporting different things.

I like argus's load metric, as it can provide a number closer to the the flows instantaneous demand for resources, and it doesn't require any knowledge of how the data was generates.   when you aggregate records together, this type of load metric approaches the average load, as the flow dur approaches the total aggregation period.  rabins.1 is just a flow aggregator.

So I would say as the rabins hold period gets larger, compared to the argus status interval, the argus 'load' metric, which is ((bytes * 8) / dur),  fastly approaches ((bytes * 8) / status interval).  And you don't have to do any calculations at all.  If you want rabins.1 to provide the general average load metric, you can use the "-M hard" option to rabins.1.  This causes rabins.1 to make the start and stop times of the aggregated flows to be the boundaries of the bins.  a "hard" substitution.  You lose data, but for some its a better average.

Hope this helps.

Carter



> On May 9, 2016, at 3:34 PM, Richard Rothwell via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
> 
> Hi List,
> 
> >>>>>>>>>
> I have inherited some code that calculates bps by:
> Multiplying bytes by 8
> Dividing by the rabins hold value.
> This seems kind of dubious to me, assuming my understanding of the hold value is correct.
> Should it not be:
> Multiplying bytes by 8
> Dividing by the dur value expressed as seconds.
> That way the time duration will either be:
> The original argus record dur for flows that fit within a bin.
> A fraction of original argus record dur for flows that cross a bin boundary.
> The same as the rabins "–M time" value for flows that straddle a bin.
> Also will need to make some tweak if the dur value happens to be zero.
> 
> >>>>>>>>>>
> Squeezing in another question.
> I am using a rabins hold time of 10s and a bin time of 60s with data sourced from a router that is using a 60s interval to detect flows.
> I suspect I need to increase the hold value to 60s or greater. Is this correct?
> 
> Regards from Richard
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20160510/2139f192/attachment.html>