Jitter and intrapacket delay

[Carter Bullard]

Hey Urtho,
remember std deviation is the square root of the variance, so
        variance = stddev ^ 2.0.

and the variance's scale is not really comparable to the mean,
as it is the scale squared.  You use std dev to get the value into
the same scale as the mean so you can eyeball quantiles, like
the +/-  (3 * stddev) for, what is it, 95% confidence that the
number is or isn't normally distributed.  that sort of thing.

It is an interesting statistical problem, what scale should a metric's
mean and variance or std dev be reported in.  these values are very  
sensitive
to the scale of the swing.  If we did seconds, the variance for the  
good stuff,
like voice and video, goes to zero very quickly (sum of squares
becomes less sensitive when its a fraction) if we do milliseconds,
its better, but we lose jitter information when the flow gets into  
the 10G and
higher speeds, where the normal interpacket arrival times is in the
nano second range, which is what I'm mostly interested in in my
research work.  Statistically, your suppose to normalize the stats so
that the mean fits into a reasonable integer range, so that the variance
has some comparable sensitivity .........

Because this has always been an issue, I'm open to doing what seems
to be the consensus on the list.  So your bet is mSec?  I could scale it
in argus, so that it reports something that is reasonable for the  
rate, but
for flows that are elastic (rate changes widely during the life of  
the flow)
you end up with a lot of processing just trying figure out where to  
report
the status record.  One of the reasons to report 5 sec status  
intervals, is
so that the stats on the jitter is reasonable (sum of squares is bounded
during this period) and we can have racluster() adjust the scale when
we aggregate the data into longer time scales.

sloss is loss between src -> dst.
dloss is loss between dst-> src.

well, 50 pps is a packet interval of 20mSec which is pretty normal for
some VoIP implementations.  do you think 50 is too high, or too low?

also remember that argus is good at dealing with silence suppression
for some rtp based codecs, so the jitter may reflect a higher packet
rate than what is actually seen for the general flow when silence
suppression is in use.

Carter


On Jul 17, 2007, at 2:28 PM, Urtho wrote:

>
> On 2007-07-17, at 18:38, Carter Bullard wrote:
>
>> Hey Urtho,
>> Remember, the values are in uSec, and jitter is really std  
>> deviation, rather
>> than variance, so the number could have been much larger.
>> With all the loss, yes you can get stdev's that are astronomical.   
>> Did you
>> calculate this from a packet file, like I suggested?   With a  
>> packet file, you
>> can actually go back and verify the numbers.
>
> variance[ms] = stddev^0.5/1000 ?
>
>>
>> not sure that I understand the NaN in the last one though.  If you
>> aggregate the data too much, you do end up with overflow conditions
>> on the sum of squares that we are carrying along.  The value is a
>> 64-bit float, so it should carry a lot of data, but when dealing with
>> uSec differences, the sum of squares can get pretty high pretty fast.
>>
>
> I get NaNs probably because of 60s flow collection interval instead  
> of default 5.
> Also the insane values are present only in case of a microflow - eg  
> 9 packet RTP flow :)
>
> So I wrote a simple perl filter that shows me only abnormal stuff  
> and I see that a lot of my (long) calls have non standard 50pps RATE.
> Will have to investigate.
>
> Small question - does destination packet loss mean - packet lost in  
> src->dst dir or quite the opposite ?
>
> Anyway - thanks for the great piece of software !!!!
>
> Urtho,
>

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20070717/aabf52dd/attachment.html>