This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Jitter graph analysis needed for RTP stream

0

Hi

I have a couple of RTP streams using FIFO as the QoS strategy on one and CBWFQ on the other for performance comparison. Using Wireshark I have ran the RTP stream analysis to get the jitter and delta values in graph format.

https://dl.dropboxusercontent.com/u/39248217/RTP%20jitter%20CBWFQ.jpg https://dl.dropboxusercontent.com/u/39248217/RTP%20jitter%20FIFO.jpg

I've edited the Y-axis so it fits into the graph, but FIFO has much higher values (indicating poorer performance) but just wondered what is happening here?

Please could someone shed some light as what each one is actually telling me. There's an obvious difference in how they handle the same RTP stream, but just need the depth of analysis.

Thanks very much! Dan

asked 16 Apr '13, 02:43

dscott1709's gravatar image

dscott1709
11335
accept rate: 0%

edited 16 Apr '13, 02:43


2 Answers:

0

As I already mentioned in your other question

http://ask.wireshark.org/questions/20456/fifo-vs-cbwfq-throughput-graph-comparison

it is hard to interpret a graph without any information about the QoS policy used and some information about the rest of the traffic that passed the monitored device (and line).

Especially regarding the RTP jitter graphs it is pretty hard to give any good explanation without that information. So, please add more details about your test environment and your test parameters.

Regards
Kurt

answered 16 Apr '13, 04:13

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks Kurt

I'm passing an identical traffic mix of RTP video stream, FTP and ICMP over a 2MB serial between two Cisco routers to compare how each QoS scheme (FIFO and CBWFQ) peforms best and what happens. I've given CBWFQ precedence levels of: RTP 7 FTP 4 ICMP 1

Does that help to give you more insight into why these graphs are different?

Cheers Dan

(17 Apr '13, 03:13) dscott1709
(17 Apr '13, 12:39) Kurt Knochner ♦

can you please post the capture file, used to generate the graphs?

(20 Apr '13, 06:08) Kurt Knochner ♦

based on the source ports in the graphs, I assume it is the same capture file as in question: http://ask.wireshark.org/questions/20456/fifo-vs-cbwfq-throughput-graph-comparison

(20 Apr '13, 08:12) Kurt Knochner ♦

0

Indeed there's little to tell, other than the remark the there are a lot of markers set, which is unusual, and that there are "Wrong seq number" markers in your FIFO graph output, which raises doubt about the type of stream you analyze.

answered 16 Apr '13, 08:37

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

I have to admit i'm a basic user of Wireshark, so I've selected my RTP stream, clicked Telephony - RTP - Stream Analysis - selected the stream - chose graph. This is what it gave me, so not sure why there would be more markers in place to be honest. there's probably wrong sequence numbers because there was high congestion and this caused delay issues (which i wanted to happen to test which QoS scheme performs best at threshold). Does that help? Thanks, Dan

(17 Apr '13, 03:12) dscott1709

The stream analysis was primarely designed for G.711 your milage with other codecs may vary. Fore one the marker bit has different meaning in Audio and Video.

(20 Apr '13, 16:02) Anders ♦

Is there a difference for the jitter calculation based on the codec used? RTP contains the same timestamp information, regardless of the codes.

However, the jitter calculation does indeed not work for the video stream in that capture file!??!

(21 Apr '13, 07:36) Kurt Knochner ♦

In video streams you can have more than one packet with the same time stamp if I remember correctly. The marker bit indicating the last one(?)I would guess this throws the jitter analysis off.

(21 Apr '13, 10:45) Anders ♦

looking at the capture file again, I can confirm your assumption. There are multiple frames with the same timestamp, while the last frame with that timestamp has the marker bit set.

Thanks for this hint!

(21 Apr '13, 11:38) Kurt Knochner ♦