How does Wireshark calculate the round-trip times used in the TCP Stream Graph > Round Trip Time Graph? Am I correct in thinking that Wireshark calculates the round-trip time by taking the difference between the time stamp of the data packet and the time stamp of the corresponding ACK packet, as seen by the Wireshark system that is doing the capturing? If so, wouldn't that mean that the round-trip time graph is pretty much meaningless if the capture is done on the client and the client is the data receiver? We have four times: Time 1: The data packet is transmitted by the server. Time 2: The data packet is received by the client. Time 3: The ACK is transmitted by the client. Time 4: The ACK is received by the server. The true round-trip time is the difference between time 1 and time 4. If we're capturing on the client, we see only time 2 and time 3. The difference between these two times represents the client response latency, not the round-trip time. I find the Round Trip Time Graph to be useful. I want to make sure I'm not using it when it's not showing me valid data. So, am I correct in thinking that the Round Trip Time Graph is only meaningful when the traffic is captured at or near the sender, or does Wireshark have a different method for calculating the round-trip time? asked 17 Jan '11, 12:10  Jim Aragon |
2 Answers:
I guess I'll answer my own question, after doing some research, since no one else did. If you're looking at two packets, an initial packet of some sort and a response packet, the RTT is not accurate unless the packets are captured on or very near the sender of the initial packet. For example, a TCP data packet and the corresponding ACK packet, or a DNS query and the DNS response, or a DHCP DISCOVER and the corresponding DHCP OFFER. The farther you are from the sending machine, the more of the round-trip path is omitted from the RTT calculation. However, as Jasper points out in this post, there is a special case for measuring the initial RTT of a TCP session when you capture all three packets of the TCP three-way handshake. In that case, the time difference between the SYN (first packet) and the ACK (third packet) of the three-way handshake includes all components of a round trip regardless of where the capturing device is placed. Of course, this technique only shows the initial RTT at the start of the TCP conversation. It does not allow you to calculate RTTs that occur later in the conversation, after the three-way handshake. answered 06 Apr '12, 14:43 Jim Aragon |
It's all about perspective and what you are trying to measure. In any capture scenario, there are always 2 segments (for lack of a better word) over which packets traverse between client and server. The 1st segment is from client to capture point, and the 2nd is from capture point to server. RTT is calculated from the point at which Wireshark captures the data and yes, RTT is always valid (barring any bugs of course), but it's valid from the perspective of Wireshark, not from the perspective of the client (or server). If you're trying to measure end-to-end RTT, then you need to capture as close to the client as possible. If, on the other hand, you are interested in determining server processing time, then you need to capture as close to the server as possible. Capture points lying somewhere in between client and server will yield RTT's also somewhere in between total RTT and server processing time. This may or may not be as useful to someone, but it all depends on what you trying to measure. answered 09 Apr '12, 07:38  cmaynard ♦♦ |
