In addition, packets time-stamped by different cores might be time-stamped in one order and added to the queue of packets for libpcap to read in another order, so time stamps might not be monotonically increasing.
Some capture devices on some platforms can provide time stamps for packets; those time stamps are usually high-resolution time stamps, and are usually applied to the packet when the first or last bit of the packet arrives, and are thus more accurate than time stamps provided by the host operating system. Those time stamps might not, however, be synchronized with the host operating system's clock, so that, for example, the time stamp of a packet might not correspond to the time stamp of an event on the host triggered by the arrival of that packet.
Depending on the capture device and the software on the host, libpcap might allow different types of time stamp to be used. The pcap_list_tstamp_types(3PCAP) routine provides, for a packet capture handle created by pcap_create(3PCAP) but not yet activated by pcap_activate(3PCAP), a list of time stamp types supported by the capture device for that handle. The list might be empty, in which case no choice of time stamp type is offered for that capture device. If the list is not empty, the pcap_set_tstamp_type(3PCAP) routine can be used after a pcap_create() call and before a pcap_activate() call to specify the type of time stamp to be used on the device. The time stamp types are listed here; the first value is the #define to use in code, the second value is the value returned by pcap_tstamp_type_val_to_name(3PCAP) and accepted by pcap_tstamp_type_name_to_val(3PCAP).
Time stamps synchronized with the system clock can go backwards, as the system clock can go backwards. If a clock is not in sync with the system clock, that could be because the system clock isn't keeping accurate time, because the other clock isn't keeping accurate time, or both.
Host-provided time stamps generally correspond to the time when the time-stamping code sees the packet; this could be some unknown amount of time after the first or last bit of the packet is received by the network adapter, due to batching of interrupts for packet arrival, queueing delays, etc..
By default, when performing a live capture or reading from a savefile, time stamps are supplied as seconds since January 1, 1970, 00:00:00 UTC, and microseconds since that seconds value, even if higher-resolution time stamps are available from the capture device or in the savefile. If, when reading a savefile, the time stamps in the file have a higher resolution than one microsecond, the additional digits of resolution are discarded.
The pcap_set_tstamp_precision(3PCAP) routine can be used after a pcap_create() call and after a pcap_activate() call to specify the resolution of the time stamps to get for the device. If the hardware or software cannot supply a higher-resolution time stamp, the pcap_set_tstamp_precision() call will fail, and the time stamps supplied after the pcap_activate() call will have microsecond resolution.
When opening a savefile, the pcap_open_offline_with_tstamp_precision(3PCAP) and pcap_fopen_offline_with_tstamp_precision(3PCAP) routines can be used to specify the resolution of time stamps to be read from the file; if the time stamps in the file have a lower resolution, the fraction-of-a-second portion of the time stamps will be scaled to the specified resolution.
The pcap_get_tstamp_precision(3PCAP) routine returns the resolution of time stamps that will be supplied; when capturing packets, this does not reflect the actual precision of the time stamp supplied by the hardware or operating system and, when reading a savefile, this does not indicate the actual precision of time stamps in the file.