{
    "mode": "man",
    "parameter": "pcap-tstamp",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/pcap-tstamp/7/json",
    "generated": "2026-09-19T08:03:21Z",
    "sections": {
        "NAME": {
            "content": "pcap-tstamp - packet time stamps in libpcap\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "When capturing traffic, each packet is given a time stamp representing, for incoming packets,\nthe  arrival  time  of  the  packet  and,  for outgoing packets, the transmission time of the\npacket.  This time is an approximation of the arrival or transmission time.  If  it  is  sup‐\nplied  by  the operating system running on the host on which the capture is being done, there\nare several reasons why it might not precisely represent the arrival or transmission time:\n\nif the time stamp is applied to the packet when  the  networking  stack  receives  the\npacket,  the networking stack might not see the packet until an interrupt is delivered\nfor the packet or a timer event causes the networking device driver to poll for  pack‐\nets,  and the time stamp might not be applied until the packet has had some processing\ndone by other code in the networking stack, so there might be a significant delay  be‐\ntween  the  time when the last bit of the packet is received by the capture device and\nwhen the networking stack time-stamps the packet;\n\nthe timer used to generate the time stamps might have low resolution, for example,  it\nmight  be a timer updated once per host operating system timer tick, with the host op‐\nerating system timer ticking once every few milliseconds;\n\na high-resolution timer might use a counter that runs  at  a  rate  dependent  on  the\nprocessor  clock  speed,  and  that clock speed might be adjusted upwards or downwards\nover time and the timer might not be able to compensate for all those adjustments;\n\nthe host operating system's clock might be adjusted over time to match a time standard\nto which the host is being synchronized, which might be done  by  temporarily  slowing\ndown or speeding up the clock or by making a single adjustment;\n\ndifferent CPU cores on a multi-core or multi-processor system might be running at dif‐\nferent  speeds,  or  might  not  have time counters all synchronized, so packets time-\nstamped by different cores might not have consistent time stamps;\n\nsome time sources, such as those that supply POSIX \"seconds since the Epoch\" time,  do\nnot  count  leap  seconds, meaning that the seconds portion (tvsec) of the time stamp\nmight not be incremented for a leap second, so that the fraction-of-a-second  part  of\nthe  time stamp might roll over past zero but the second part would not change, or the\nclock might run slightly more slowly for a period before the leap second.\n\nFor these reasons, time differences between packet time stamps  will  not  necessarily  accu‐\nrately reflect the time differences between the receipt or transmission times of the packets.\n\nIn  addition,  packets time-stamped by different cores might be time-stamped in one order and\nadded to the queue of packets for libpcap to read in another order, so time stamps might  not\nbe monotonically increasing.\n\nSome capture devices on some platforms can provide time stamps for packets; those time stamps\nare usually high-resolution time stamps, and are usually applied to the packet when the first\nor  last  bit  of the packet arrives, and are thus more accurate than time stamps provided by\nthe host operating system.  Those time stamps might not, however, be  synchronized  with  the\nhost  operating  system's  clock,  so that, for example, the time stamp of a packet might not\ncorrespond to the time stamp of an event on the host triggered by the arrival of that packet.\nIf they are synchronized with the host operating system's clock, some of  the  issues  listed\nabove  with  time  stamps supplied by the host operating system may also apply to time stamps\nsupplied by the capture device.\n\nDepending on the capture device and the software on the host, libpcap might  allow  different\ntypes  of  time  stamp to be used.  The pcaplisttstamptypes(3PCAP) routine provides, for a\npacket capture handle created by pcapcreate(3PCAP)  but  not  yet  activated  by  pcapacti‐\nvate(3PCAP), a list of time stamp types supported by the capture device for that handle.  The\nlist  might  be empty, in which case no choice of time stamp type is offered for that capture\ndevice.  If the list is not empty, the pcapsettstamptype(3PCAP) routine can be used  after\na  pcapcreate()  call and before a pcapactivate() call to specify the type of time stamp to\nbe used on the device.  The time stamp types are listed here; the first value is the  #define\nto use in code, the second value is the value returned by pcaptstamptypevaltoname(3PCAP)\nand accepted by pcaptstamptypenametoval(3PCAP).\n\nPCAPTSTAMPHOST - host\nTime  stamp provided by the host on which the capture is being done.  The precision\nof this time stamp is unspecified; it might or might not be synchronized  with  the\nhost operating system's clock.\n\nPCAPTSTAMPHOSTLOWPREC - hostlowprec\nTime stamp provided by the host on which the capture is being done.  This is a low-\nprecision time stamp, synchronized with the host operating system's clock.\n\nPCAPTSTAMPHOSTHIPREC - hosthiprec\nTime  stamp  provided  by  the  host on which the capture is being done.  This is a\nhigh-precision time stamp, synchronized with the host operating system's clock.  It\nmight be more expensive to fetch than PCAPTSTAMPHOSTLOWPREC.\n\nPCAPTSTAMPHOSTHIPRECUNSYNCED - hosthiprecunsynced\nTime  stamp  provided  by  the  host on which the capture is being done.  This is a\nhigh-precision time stamp, not synchronized with the host operating system's clock.\nIt might be more expensive to fetch than PCAPTSTAMPHOSTLOWPREC.\n\nPCAPTSTAMPADAPTER - adapter\nTime stamp provided by the network adapter on which  the  capture  is  being  done.\nThis  is a high-precision time stamp, synchronized with the host operating system's\nclock.\n\nPCAPTSTAMPADAPTERUNSYNCED - adapterunsynced\nTime stamp provided by the network adapter on which  the  capture  is  being  done.\nThis is a high-precision time stamp; it is not synchronized with the host operating\nsystem's clock.\n\nTime  stamps  synchronized with the system clock can go backwards, as the system clock can go\nbackwards. If a clock is not in sync with the system clock, that could be because the  system\nclock  isn't  keeping  accurate time, because the other clock isn't keeping accurate time, or\nboth.\n\nHost-provided time stamps generally correspond to the time when the time-stamping  code  sees\nthe  packet;  this  could  be  some unknown amount of time after the first or last bit of the\npacket is received by the network adapter, due to batching of interrupts for packet  arrival,\nqueueing delays, etc..\n\nBy  default,  when performing a live capture or reading from a savefile, time stamps are sup‐\nplied as seconds since January 1, 1970, 00:00:00 UTC, and  microseconds  since  that  seconds\nvalue,  even if higher-resolution time stamps are available from the capture device or in the\nsavefile.  If, when reading a savefile, the time stamps in the file have a higher  resolution\nthan one microsecond, the additional digits of resolution are discarded.\n\nThe pcapsettstampprecision(3PCAP) routine can be used after a pcapcreate() call and after\na  pcapactivate()  call  to specify the resolution of the time stamps to get for the device.\nIf  the  hardware  or  software  cannot  supply   a   higher-resolution   time   stamp,   the\npcapsettstampprecision() call will fail, and the time stamps supplied after the pcapacti‐\nvate() call will have microsecond resolution.\n\nWhen    opening    a   savefile,   the   pcapopenofflinewithtstampprecision(3PCAP)   and\npcapfopenofflinewithtstampprecision(3PCAP) routines can be used to specify  the  resolu‐\ntion  of  time  stamps  to be read from the file; if the time stamps in the file have a lower\nresolution, the fraction-of-a-second portion of the time stamps will be scaled to the  speci‐\nfied resolution.\n\nThe  pcapgettstampprecision(3PCAP) routine returns the resolution of time stamps that will\nbe supplied; when capturing packets, this does not reflect the actual precision of  the  time\nstamp  supplied  by  the hardware or operating system and, when reading a savefile, this does\nnot indicate the actual precision of time stamps in the file.\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "pcap(3PCAP)\n\n14 July 2020                              PCAP-TSTAMP(7)",
            "subsections": []
        }
    },
    "summary": "pcap-tstamp - packet time stamps in libpcap",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "pcap",
            "section": "3PCAP",
            "url": "https://www.chedong.com/phpMan.php/man/pcap/3PCAP/json"
        },
        {
            "name": "PCAP-TSTAMP",
            "section": "7",
            "url": "https://www.chedong.com/phpMan.php/man/PCAP-TSTAMP/7/json"
        }
    ]
}