It’s often useful to understand how long it takes for a request to get responded to. This helps you gauge how well a client or server is keeping up. This type of measurement can also be done at different layers; however there are some tricks you’ll have to learn.
In order to filter on the difference in time, you can use FrameVariable.TimeDelta property. This value represents the time from the last physical frame in the trace. One side effect of this is that you can’t filter the time delta that results between two filtered frames or two frames in a specific conversation. Leading to perhaps more confusion, the time delta column you see is updated based on the filtered information.
The following filter will find any frame with a time delta greater than 1 second.
FrameVariable.TimeDelta > 10000000
First you’ll notice that you have to convert the value based on .1 microsecond chunks. In the example above, 1 second = 1000000 microseconds = 10,000,000. Second, if you view the Time Delta column, you might see some inconsistencies. The time we portray here is based on the last visible frame. But the filter works on the last physical frame. So as soon as any other filter is applied, including clicking in the conversation tree, the values you see in the Time Delta column will not match a Time Delta filter you apply on top of it. Finally responses don’t always follow requests, so this method doesn’t always work.
Response Times for a Specific Protocol
The fact that we can only filter TimeDelta based on the last physical frame reveals a problem if you want to determine response times for a specific protocol. To get around this problem, save a filtered version of your trace so frames you want to filter on are in your saved file. For instance if you want to see SMB response times, find a specific SMB conversation and save that out to a separate file. Then open that new capture file and use the time delta filter to find your longer response times.
Finding Slow Servers
Using the TimeDelta filter to find slow responding servers and services at any protocol layer is a great way to locate performance issues. Just remember to first save a filtered version of your trace based on the protocol and connection, then type in your FrameVariable.TimeDelta filter. Another great option here is using the Network Monitor API to programmatically analyze a trace for response times. A great example of this is vRTA which I reference in this blog, though goes beyond just response times.