PCR App Byte Ratio question...
gerth at graphics.stanford.edu
Fri Sep 26 17:24:33 EDT 2014
On the terminology, in the release code, ABR was renamed PCR (producer/consumer ratio)
I'm not stathead either but it seems to me you need to think carefully
about what you're trying to model when playing with the metrics
For example, since pcr == ( s_ab - d_ab) / (s_ab + d_ab), and t_ab = s_ab + d_ab,
then t_ab * pcr = s_ab - d_ab
Thus denormalizing the ratio and giving back the absolute difference. Indeed, this
shows that given the pcr and t_ab, one can retrieve both s_ab and d_ab.
One can also look at the aggregate pcr over a set of flows by simply summing
the s_ab and d_ab before calculating the pcr. I've played a little bit with
this, but have done nothing systematic yet. One needs to form a hypothesis to test.
Anyway, it's clear that looking at the distribution of metrics for individual flows
would be different than looking at the aggregates, but I'm pretty sure that the
stat literature discusses this kind of analysis
I have no intuition about what pcr*duration might signify
John Gerth gerth at graphics.stanford.edu Gates 378 (650) 725-3273
On 9/26/14, 1:44 PM, Craig Merchant wrote:
> Hey, Carter…
> I’ve been playing around with the app byte ratio in our environment. I’ve had some success feeding it to a machine learning application (Prelert).
> One thing that occurred to me was if you saw any value in using a weighted version of ABR, such as ABR * total bytes in the flow or ABR * duration of
> the flow. I’m wondering if lots of small flows or short flows might distort the average ABR for a given host/protocol/port when compared to a long
> running or high volume flow.
> Just curious what your thoughts are on the matter… I’m not a quant…
More information about the argus