Most network administrators have access to a device or software that lets them capture packets off their network and decode them. And almost every network administrator wishes they were a little more skilled at reading the trace files these tools produce.
One of the easiest ways to make their output a little more intelligible is to understand the timestamps. Nearly every analyzer displays packet times three ways at the same time: "Absolute time", "relative time" and "delta time". At face value, these fields are pretty simple, but it takes a little more thought to get useful info from them:
- Absolute time is the time of day the packet was seen by the analyzer. While this might sound useful, it is rarely so. You might use this if you are troubleshooting and wanted to look for packets sent at the same time as some event in another log, like the Windows Event Viewer on a server. The problem is, with hundreds of thousands of packets per second zooming around, if your analyzer is a few seconds (or likely minutes) off it's difficult to tell with any certainty that a specific packet was involved in your problem. This can also drive you nuts if multiple timezones are involved. NTP is your friend.
- Relative time is the time since the beginning of the capture. That is, it works like Absolute time, but the first packet in the file will usually be at 0 seconds. Relative time is useful for analyzing application performance at a job or task level. For instance, you can subtract the relative time of the first packet in a database transfer from the relative time of the last packet and tell how long the transfer took.
- Delta time is the time since the previous frame. i.e., If frame 100 has a Delta time of 35 ms, then there were 35 ms of silence between frames 99 and 100. This information is very useful for identifying network problems related to latency, but there's a trick. With potentially thousands of conversations going on, what you really want to know is the delta time from the last packet in the same session, but odds are strong that the last packet the analyzer saw was from another conversation. So, to use this information, you need to filter by conversation.
So, once you get your filters set to a single conversation, scan down the Delta time field and get a feel for how long it takes your client and server to respond to each other. A very typical pattern is for alternating long and short delta times. That is, one packet has a relatively short time and the next packet has a relatively long time, then the next has a relatively short time, etc. The important thing you can learn from this field and pattern is whether the server is waiting on the network, or the network is waiting on the server.
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.
