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

RTT Graph showing values higher than tcp.analysis.ack_rtt



I'm trying to understand how the RTT Graph (Statistics --> TCP StreamGraph --> RTT graph) relates to the ACK RTT.

What I'm seeing, for a capture with a single TCP connection, is that the graph has much higher values for many data points than the calculated field tcp.analysis.ack_rtt. In fact, when sorting by the RTT column (I added it), I have only 5 points above 0.01s, whereas the graph has hundreds!

Here is the top end of the RTTs (sorted ascending):

alt text

Here is the graph: alt text

asked 16 Dec '14, 14:47

yoggiy's gravatar image

accept rate: 0%

One Answer:


The values for tcp.analysis.ack_rtt are correct. Wireshark does not implement the Round Trip Time Graph correctly. This is a known bug. (See Bug 10722 at the Wireshark Bugzilla.) Round-Trip Time is supposed to be the time between a data packet and an ACK packet sent IN RESPONSE TO that data packet. ACKs are cumulative, and due to Delayed ACK, an ACK can acknowledge multiple data packets, but only the time between the last data packet in the series (the one that actually triggered the ACK) and the ACK is a valid RTT. However, Wireshark plots a dot on the Round-Trip Time graph for every data packet, not just the one that triggered the ACK.

tcp.analysis.ack_rtt is plotted once per ACK, not once per data packet. If you want a graph of Round Trip Time values, go to the Advanced IO Graph, select MAX(*) as the Calc type and enter tcp.analysis.ack_rtt as the field name.

When Delayed ACKs are not in use, and there is one ACK packet for each data packet, the Round Trip Time graph should be correct.

answered 16 Dec '14, 18:40

Jim%20Aragon's gravatar image

Jim Aragon
accept rate: 24%

Thanks Jim. I can't explain why Google didn't find that!!?

(18 Dec '14, 15:50) yoggiy