perfSONAR User Q&A and Other Discussion

[Aaron Brown <>]

Hey Pedro,

Comments inline

Cheers,

Aaron

On Mar 20, 2013, at 3:16 PM, Pedro Queirós <> wrote:

Thanks for clearing that up Aaron. So I suppose there's no way of getting

the inter-packet jitter from the database, nor the owamp tool.

owping can give you that if you want it by specifying the  -v flag. e.g.

owping -v owamp.wash.net.internet2.edu

Approximately 13.0 seconds until results available

--- owping statistics from [lab-ip6.internet2.edu]:33300 to [owamp.wash.net.internet2.edu]:60864 ---

SID: 00160034d4f48a8747cd898bc573513b

seq_no=0          delay=11.9 ms (sync, err=0.0973 ms)

seq_no=1          delay=11.9 ms (sync, err=0.0973 ms)

seq_no=2          delay=11.9 ms (sync, err=0.0973 ms)

seq_no=3          delay=11.9 ms (sync, err=0.0973 ms)

seq_no=4          delay=11.9 ms (sync, err=0.0973 ms)

seq_no=5          delay=11.9 ms (sync, err=0.0973 ms)

seq_no=6          delay=11.9 ms (sync, err=0.0973 ms)

seq_no=7          delay=11.9 ms (sync, err=0.0973 ms)

…

It's just not saved because that would produce an absurd amount of data (and owamp already produces a large amount…).

Is there anywhere I can read more about that 95th percentile - 50th percentile

jitter?

In http://www.internet2.edu/performance/owamp/owping.man.html it states

that "OWAMP reports the the 95th percentile of delay - 50th percentile of delay."

Is that a minus sign? Or is it used to specify a range, e.g., you take all the 

packets (or buckets?) between the 50th and 95th percentile and use those to 

calculate jitter?

Subtract the median (50th percentile) from the 95th percentile. I can't recall the logic behind why that was chosen as the jitter metric, but Jeff (cc'd) might.

I appreciate your patience on this matter.

Kind Regards,

Pedro

On Wed, Mar 20, 2013 at 5:12 PM, Aaron Brown <> wrote:

Yep, it takes those buckets and calculates the jitter as 95th percentile - 50th percentile.

Cheers,

Aaron

On Mar 20, 2013, at 1:08 PM, Alan Whinery <> wrote:

Aaron,

while you're on that thought -- is that histogram-derived jitter what's reported by owping? I have noticed that owping reports "jitter" and powstream does not...

-Alan

On 3/20/2013 7:05 AM, Aaron Brown wrote:

Hey Pedro,

Each row (a bucket) corresponds to a group of packets, so it's the equivalent of saying "in minute X, there were 597 packets with 50ms delay, 2 packets with 51ms delay, and 1 packet with 54ms delay". You have to use the OWPBUCKETWIDTH parameter to figure out what to multiply times 'i' to get the delay for each bucket. That histogram should give you a usable concept of jitter for each 1 minute interval. However, if you want the inter-packet jitter, there's no way to get that from the database.

Cheers,

Aaron

On Mar 20, 2013, at 12:50 PM, Pedro Queirós <> wrote:

Hi Aaron,

yes, I've checked that earlier. I'm not seeing how I can generate jitter stats from that table,

since there aren't timestamps of individual packets.

Do you guys actually do this? Or know if anyone has done that before?

Kind Regards,

Pedro

On Wed, Mar 20, 2013 at 3:48 PM, Aaron Brown <> wrote:

Hey Pedro,

There's a description of how to interpret the values of the DELAY table in http://anonsvn.internet2.edu/svn/perfSONAR-PS/trunk/perfSONAR_PS-perfSONARBUOY/doc/owamp_database_schema.txt . Let me know if it's confusing, or if you have specific questions.

Cheers,

Aaron

On Mar 20, 2013, at 11:37 AM, Pedro Queirós <> wrote:

Thank you Jeff and Aaron for your replies.

So, if I correctly interpreted what Aaron stated, it's just impossible

to get the mean value of the delay. I must use the DELAY table

to somehow get the median.

I'm not understanding how can I calculate jitter based on the DELAY

table. Can someone please enlighten me on this?

Thanks for your time,

Pedro

On Thu, Mar 14, 2013 at 5:00 PM, Jeff Boote <> wrote:

Another doubt of mine concerns the following phrase: "The maxerr has the 

maximum NTP error seen." Can you please elaborate on this? 

What error are you referring to? The error in time synch between the machine

and it's time reference?

That's my recollection, but I'm not positive. In general, it's just a gauge of how trustworthy the numbers are. e.g. if the delay says 30ms, but the error is 20ms, the result is unlikely to be as useful.

IIRC, It is the sum of the max error reported by ntpq on both the sending and receiving machines.

Jeff