Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

OK, this may seem trivial but due to the nature of testing required for my application, I need to get precise timestamps.

I am using WireShark to analyze packets.

Suppose I have a network with 2 hosts h1 and h2.

h1 and h2 are connected with each other via interfaces h1-eth0 and h2-eth0 respectively.

When I run Wireshark on host h1 to capture the interface h1-eth0, can I be absolutely certain that the timestamps being recorded correspond to the system time of host h1?

Although this should be the case, besides your useful remarks, it would really help if I could get a link citing the same (this is just so I may formalize my application).

[CONCLUDING REMARKS]: manpage for the tcpdump's timestamp module. PCAP-TSTAMP.

NOTE: The man page is written by Guy Harris himself. :)


When capturing traffic, each packet is given a time stamp representing, for incoming packets, the arrival time of the packet and, for outgoing packets, the transmission time of the packet. This time is an approx‐ imation of the arrival or transmission time.

share|improve this question
"I just found a citation supporting Guy Harris's answer ... manpage for the tcpdump's timestamp module." You know who wrote that man page, right? :-) (I.e., if you're looking for an independent citation for my claim, you haven't found it.) – user137177 Jun 18 '13 at 23:40
Since they were part of OpenSuse's documentation, they worked for me (I also designed a few experiments using tc with throttled bandwidths which supported you). Although I'm curious by your comment. Are man pages known to be defective in general? – spiritusozeans Jun 18 '13 at 23:53
No, my comment was a sly way of saying I WROTE that man page, so it shouldn't exactly be surprising that it agrees with what I said here. :-) – user137177 Jun 19 '13 at 6:18
You did! That's so Awesome! Forgive my ignorance (I'm a noob) - but who are you exactly? I realize this question is out of this site's scope, yet amazing a budding computer engineer might be an incentive :) – spiritusozeans Jun 19 '13 at 16:45
I'm one of the core libpcap, tcpdump, and Wireshark developers, and have spent more time than I'd like plowing through the packet capture code path on various UN*Xes. – user137177 Jun 20 '13 at 2:47
up vote 3 down vote accepted

Suppose I have a network with 2 hosts h1 and h2.

h1 and h2 are connected with each other via interfaces h1-eth0 and h2-eth0 respectively.

When I run Wireshark on host h1 to capture the interface h1-eth0, can I be absolutely certain that the timestamps being recorded correspond to the system time of host h1?

If you run Wireshark (or tcpdump or WinDump or snoop or Microsoft Network Monitor or Sniffer or OmniPeek or Commview or any other sniffer; the answer is not specific to Wireshark...) on host h1, the packets are coming from a capture mechanism in the networking stack of the OS running on host h1, and the time stamps correspond either to the time at which the packet was time-stamped by that networking stack (i.e., timestamped by host h1) or, in some cases, by the time at which the packet was stamped by the network adapter plugged into host h1 (or, on HP-UX, by the time at which libpcap read the packet from the networking stack on host h1, as HP-UX's capture mechanism doesn't itself time-stamp packets).

So the time stamp is closest to the host time on the machine on which you're running the sniffer program. It does not necessarily correspond to the exact time, down to the microsecond or nanosecond, at which the packet arrived at host h1's network adapter (unless the network adapter is time-stamping the packets; most don't support that). There may be a delay between the time at which the packet arrived at the networking adapter and the time at which it's time-stamped, that could included:

  • the time between the arrival of the packet and the signaling of an interrupt to tell the host that a packet has arrived (there isn't necessarily an interrupt signaled for each packet);
  • the time between the signaling of the interrupt and the host responding to it;
  • the time between the host responding to the interrupt and the packet being handed to the capture mechanism;
  • the time between the packet being handed to the capture mechanism and being time-stamped by the capture mechanism.

So if by "can I be absolutely certain that the timestamps being recorded correspond to the system time of host h1?" you mean "can I be absolutely certain that the timestamps being recorded correspond, with high precision, to the system time of host h1 at the time the packet arrived?", the answer is "not necessarily, even if you're running on host h1". It's closer to the time at which the packet arrived on host h1 than to the time at which the packet was sent from host h2, but if you need to know high-precision and high-accuracy time stamp values, you'll need either specialized hardware that time-stamps packets on the networking adapter or a specially-tuned receive code path (which may mean that you'd have to hack interface driver code and networking stack code; such a specially-tuned receive code path is not, for example, a configuration option for a Linux kernel or a registry option for a Windows kernel).

(BTW, Mitch's answer applies only on Windows; there's no such routine as KeQuerySystemTime on my personal computer, for example - the packets are time stamped with a value returned by a routine named microtime.)

share|improve this answer
Ah, that's great! Thanks a lot! Just to confirm then, doesn't tcpdump use the timestamp which are present on the packet themselves -- which I understand are set by the sender rather than the receiver? In my example therefore, I'm concerned about an icmp reply from h2 carrying h2's time stamp rather than h1. Although, as you mentioned, if its closer to h1, I'm happier since it makes my application easier to build. If possible do you have any citation for the effect you are mentioning? (since I'm building a formal application, I have to prove everything I use) – spiritusozeans Jun 14 '13 at 22:48
Not all packets have time stamps in their contents, but, no, tcpdump, which uses libpcap/WinPcap just like Wireshark, prints, as the first item on a line, the same libpcap/WinPcap time stamp that Wireshark shows as the time stamp, not any time stamp that the packet might have in its contents. For ICMP Timestamp Reply messages, both it AND Wireshark will ALSO show the time stamps from the packets. – user137177 Jun 15 '13 at 1:34
And the only citations I have for the source of the time stamps is the source code to the OSes (for UN*Xes for which the source is available), man pages (for UN*Xes for which the capture mechanism has man pages and for which they give details, but those won't give full code path details), and source code to WinPcap (for Windows). – user137177 Jun 15 '13 at 1:38

Keep in mind, Wireshark is the viewer, winpcap is the capture application.

Based off of the code and a helpful post in their mailing list, the timestamp comes from KeQuerySystemTime on non-x86 systems and from a combination of KeQuerySystemTime and the rdtsc instruction on non-x86 systems.

Regardless, you should have higher than 100ns accuracy relative to the system clock.

Official description:

share|improve this answer
Thanks for your reply! Also I'm not sure as to which device's time stamp is chosen. Therefore, from the example in my question, does the timestamp shown in WireShark correspond to that of system h1 or h2? – spiritusozeans Jun 14 '13 at 19:56

You simply cannot get a precise timestamp when capturing network traffic in the configuration you mentioned, because of the following:

  • On Windows. Linux and FreeBSD you have to keep in mind that the timestamp could be off easily by at least a few milliseconds (and up to 10- 25 ms) due to the load on the host machine and the nature of the implementation of the network driver and the NIC itself. In particular network interrupt processing as well as memory allocation and the other hardware interrupt processing (such as from your hard drive) contribute to the delays. Recognizing this problem, modern operating systems typically utilize two-step interrupt processing. The split of interrupt processing into short and long segments further creates confusion as to the exact time when this or that packet was received because of all the other processes that have to take place on the same machine. As a result, you have no certainty as far as any time measurements are concerned and it is very difficult to have any kind of accuracy or precision.
  • Clock drift. Unless you have specialized hardware, over time your timestamps will drift. For example, after a few hours or days the timestamps on host h1 and on h2 would differ by seconds or more. FYI: HPET drift as per Intel specs (Oct 2004) is from 500 to 2000 ppm or 0.05% to 0.2% and the older RTC is even worse.
  • If you have a burst of traffic that exceeds the number of buffers allocated by the NIC driver you may run into packet loss or incorrect time stamping due to hardware flow control.

Simply put it is very hard to benchmark the host using winpcap running on the same host. I typically use an external packet capture appliance with a good clock, like the USC4060.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.