Wireshark’s "delta time" isn’t just about how long packets took to arrive; it’s about how long each individual packet took to be processed by the network stack, from capture to display.
Let’s see this in action. Imagine a simple web request. We’ll capture the traffic and look at the delta times.
First, fire up Wireshark and start a capture on your network interface. Then, open your web browser and navigate to a simple, non-cached page. Once the page loads, stop the capture and filter for the traffic related to that page load, likely by IP address or a specific protocol like HTTP.
Here’s what a typical capture might look like after filtering for a specific host and HTTP traffic:
No. Time Source Destination Protocol Length Info
1 0.000000 192.168.1.100 192.168.1.1 HTTP 66 GET /index.html HTTP/1.1
2 0.015432 192.168.1.1 192.168.1.100 TCP 60 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1234567 TSecr=0 WS=128
3 0.015500 192.168.1.100 192.168.1.1 TCP 60 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1234568 TSecr=1234567 WS=128
4 0.015600 192.168.1.1 192.168.1.100 HTTP 216 HTTP/1.1 200 OK (text/html)
Now, let’s look at the "Delta time" column. By default, Wireshark displays the time between consecutive packets.
- Packet 1 to Packet 2:
0.015432 - 0.000000 = 0.015432seconds. This is the time from when packet 1 was captured to when packet 2 was captured. - Packet 2 to Packet 3:
0.015500 - 0.015432 = 0.000068seconds. - Packet 3 to Packet 4:
0.015600 - 0.015500 = 0.000100seconds.
This default view tells you about the inter-packet arrival time at the capture point. But to understand latency, we need to dig deeper.
To get the per-packet latency – the time from when a packet left the source application to when it was captured by Wireshark, or the time from capture to when it was processed by the destination – we need to adjust Wireshark’s settings.
Go to Edit -> Preferences -> Protocols -> TCP. Under the "TCP" section, you’ll find "Enable per-packet TCP sequence number analysis." Check this box. This tells Wireshark to try and reconstruct the flow of data at a more granular level.
Now, let’s look at the delta time between related packets. A key insight is that the "Time" column in Wireshark is the time the packet was captured. The delta time between two packets in the capture window is the time between their captures. To understand the latency within a single flow, we need to look at the delta time relative to the previous packet of the same stream.
If you right-click on a packet and select "Follow" -> "TCP Stream," Wireshark will open a new window showing the reassembled data. In this window, the "Time" column represents the time since the first packet of that stream was captured. The delta time here is the time elapsed since the previous reassembled chunk of data arrived. This is a more accurate representation of the application-level latency for that specific data flow.
Consider the TCP handshake. Packet 1 is the client’s SYN. Packet 2 is the server’s SYN-ACK. The delta time between Packet 1 and Packet 2 in the main Wireshark window (0.015432 seconds) is the time from when the SYN was captured on the client’s interface to when the SYN-ACK was captured on the client’s interface. This includes the round-trip time (RTT) for the SYN plus the server’s processing time.
The true power comes when you analyze the delta time between the client sending data and the server acknowledging it, or vice-versa. Right-click on a client’s HTTP GET request (Packet 1 in our example) and select "Follow" -> "TCP Stream." Look at the timestamp of the GET request in the reassembled stream. Then, find the server’s HTTP 200 OK response (Packet 4). The delta time shown in the "Follow TCP Stream" window between these two points is a direct measure of the round-trip time for that specific request and response, including network travel time and server processing.
The most surprising thing is that Wireshark’s "delta time" is not a single, fixed metric. It’s context-dependent. By default, it’s inter-packet arrival time. With TCP stream following, it becomes time-since-stream-start. To get true per-packet latency, you often need to correlate timestamps between different capture points or use advanced features like TCP sequence number analysis to infer processing delays.
The "Delta time displayed" setting in Wireshark (View -> Time Display Format) is crucial. You can change this from "Seconds" to "Seconds Since Beginning Of Capture," "UTC Date and Time," and importantly, "Seconds Since Previous Displayed" (which is the default inter-packet delta). There’s also "Seconds Since Previous Captured" and "Seconds Since Previous Marked." These options let you see the time elapsed relative to different reference points.
To get the most granular per-packet latency, you’d ideally have Wireshark capturing on both the client and server. Then, you’d compare the timestamp of a packet leaving the client with the timestamp of the same packet (or its acknowledgment) arriving at the server. The difference, adjusted for clock skew, is the network latency for that packet. Wireshark itself, on a single interface, infers latency by analyzing the sequence of events in a single stream.
One often overlooked aspect is that Wireshark’s timestamps are generated by the capture library (like libpcap/WinPcap). The precision and accuracy of these timestamps depend on the operating system and hardware. High-resolution timers are essential for accurate delta time measurements, especially for very low-latency networks. If your OS or NIC has poor timer resolution, your delta times will be artificially inflated or quantized.
The next hurdle is understanding how to interpret and visualize these delta times for performance tuning, often involving comparing delta times across different network paths or under varying load conditions.