PCR App Byte Ratio question...

[John Gerth]

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