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

TCP (and others) response times

2

Can anyone provide some tips on determining response time to certain protocols? For instance, I can think of several protocols where I want to detect a network request then find how long it takes to get a response. The main one is ModbusTCP, where there is a request then a response some time later. Another could be DNS response times, or ARP response times. I know there is an option for service response times, but as luck would have it the ones I want are not there.

My solution is to export the packet data and bring into Excel and manipulate there. Very time consuming. Any tips, tricks, or ideas would be helpful!

Let me clarify my question a little more with an example. I may have a trace with one tcp connection, but the request and response is continuous. Each individual request and response has a response time, so I may have 100K packets, so 50K response times. I want to end with a histogram of response time, based on arbitrary criteria - say this port, or this type of request, or this packet size. Currently what I do is:

  1. Add columns to display: Modbus TransactionID, function code, and number of registers
  2. Filter out the TCP stream I need in the display filter
  3. Sort the data by TransactionID, and then view time starting at beginning of capture assuming that the packet number is a sub sort, as in there should be two packets (sometimes more) with the same transactionID, and I want the request first, response second, and this should be the case with the packet number.

But then I export into Excel, and have to do some tests - I need two transactionIDs in a row that are the same; if so, then I can do a time delta between them and then for that function code and transactionID, I then have a response time. I do this for all the data, ignoring the cases where I have no response, or multiple requests for a response, and I can then plot and get a histogram.

Is there a way to get this in the IOgraph as part of Wireshark? I will do without the histogram, but I can live without the histogram, but a realtime response graph on the IOgraph would be fantastic. I can then just watch to see how the devices perform over time, and instantly see where we may have an issue to address.

If I need to do some scripting, I can give it a try. Can anyone point me to a suggested scripting language? I took cursory look at Lua, so I assume that is what I should start with as it is integrated with Wireshark? I suppose if I want to get really fancy - LUA script -> GNUPlot then I can get my data and a graph at the same time?

asked 21 Sep '10, 03:52

Bob%20Jones's gravatar image

Bob Jones
1.0k2515
accept rate: 21%

edited 21 Sep '10, 06:29

hello I would like to ask how me messure the requestand responce time of SMB ? Please send me on [email protected]hotmail.com.

(29 Nov '12, 19:47) imran

hello I would like to ask how we messure the Request and responce time of SMB?

(29 Nov '12, 19:48) imran

2 Answers:

2

Be sure you have a column setup for interpacket deltas (Edit->Prefs->Columns - add a column for "Delta Time Displayed"). This will show you the time delta between packets. Now you have to filter out the conversations that you want to view response times for. There are, of course, a few caveats. For TCP conversations you'll need to watch for the original SYN packet (am I the only one that loves saying "Original SYN"??) then look at the delta between that packet and the returning SYN-ACK. This delta, for the most part, will represent network flight time - How long it took to get from tier A to tier B. NORMALLY the SYN/SYN-ACK process involves little to no system processing time and, so, is a fairly reliable gauge of end-to-end latency. Things get more difficult if you want to monitor an entire conversation and understand the variable response times from either tierA or tierB. The TCP Flow Graph (Stats->Flow Graph) will break down the response times over time but they can be misleading depending on the volatility of the network.


 For DNS response times you can filter out the conversation and just look at the deltas between the request going out and the response coming in.  There are a few different ways to handle this kind of thing en masse - either with Excel or the raw dump and a good scripting language.

Those are my $.02, others may have better input.

answered 21 Sep '10, 06:10

GeonJay's gravatar image

GeonJay
4705922
accept rate: 5%

I think that looking at the delta times between packets of the tcp handshake does provide a good indicator for network response time but may not shed any light on application response time. Additionally, if the trace was taken on the server then looking at time delta between syn and syn ack would be a misleading indicator of network response time. Rather, looking at the syn ack and ack delta would be more accurate due to where the trace was taken.

(22 Sep '10, 18:19) 9691ekiM

0

Wow...and I thought it was a simple response time question ;-)

This is a pretty good writeup, taken from a Sharkfest presentation, see if it puts you on the right path.

Wireshark Charts & IO Graphs

answered 21 Sep '10, 06:52

GeonJay's gravatar image

GeonJay
4705922
accept rate: 5%

Hi Geon You mean to say, Delta Time displays the difference between request and response times?

Regards. Sudin

(17 Sep '14, 08:01) Sud

Delta Time displays the time difference between packets, regardless of whether they are requests or responses, but you could apply a display filter so that Wireshark is showing only the requests and responses that you're concerned with. Make sure you're using the delta time between displayed packets, not the delta time between captured packets.

For some protocols, Wireshark will calculate the time between the request and response for you. Wireshark has the dns.time field, the http.time field, the smb.time field, and the smb2.time field. These time fields are found in the response packet, assuming that both the request and the response are in the trace. I do not see a time field for Modbus.

(17 Sep '14, 08:42) Jim Aragon