Re: timestamp in pcap/tcpdump

[Guy Harris <guy () alum mit edu>]

On Nov 26, 2012, at 12:56 AM, Cheng Cheng <ccheng.leo () gmail com> wrote:

> In order to get the accurate receiving timestamp of a packet on the NIC device not supporting hardware timestamping, 
> can I modify the NIC device driver code to update skb_shared_hwtstamp struct by using TSC in RX routine?

Well, that's arguably an abuse of skb_shared_hwtstamp, as it's *not* the NIC that's time-stamping the packet.  If the 
NIC timestamps the packet, the time stamp can be applied either at the time it detects the first bit of the packet or 
at the time it detects the last bit of the packet (depending on how it decides to time-stamp the packet); if the driver 
timestamps the packet, the time stamp cannot be applied before the driver is called, so there is, at minimum, a delay 
due to the time it takes to respond to the interrupt and call the driver.  You would also want to disable any form of 
"interrupt batching", including polling, so that there isn't a delay between the point at which the NIC receives the 
packet and when the driver is called.

It would probably be not be considered A Good Idea to put a change such as that into the official kernel source; if you 
tried to get a patch for that accepted, it might not be accepted.

But, in theory, you could do that.  The TSC wouldn't be sufficient by itself, as it just counts processor ticks, and 
you'd have to convert those to seconds-since-the-Epoch, that being what pcap and applications using pcap expect.  You 
probably want to use something such as do_gettimeofday(), which returns seconds-since-the-Epoch and, as far as I know, 
uses the TSC  on x86 processors, if the TSC is available (but you're probably not running on an 80386 or 80486, so it 
should be available), to provide higher-resolution times.

> Will pcap support to retrieve such timestamp from skb_shared_hwtstamp?

Recent versions of pcap (I forget whether that was added in 1.2.0 or 1.3.0) support:

        pcap_list_tstamp_types(), which lists all the time stamp types supported by an interface;

        pcap_set_tstamp_type(), which sets the time stamp type to use.

The default time stamp type is PCAP_TSTAMP_HOST, which is "whatever the capture mechanism gives you by default", which 
would be the software time stamp on Linux (and most other platforms).  The other options available on Linux, if your 
kernel supports hardware timestamping, are:

        PCAP_TSTAMP_ADAPTER - hardware time stamp, shifted to synchronize it with the system time stamp;

        PCAP_TSTAMP_ADAPTER_UNSYNCED - hardware time stamp, *not* shifted;

both of which are seconds-since-the-Epoch (well, actually, PCAP_TSTAMP_ADAPTER_UNSYNCED might be a count of seconds 
that have elapsed since the Epoch, rather than seconds-since-the-Epoch, but you *really* don't want me to start ranting 
about POSIX and leap seconds...).

If the program doing the capture supports those two APIs, as recent versions of tcpdump do, you can get the hardware 
time stamp or, in your case, the pretends-to-be-hardware time stamp.  With tcpdump, you'd use the −j flag to set it, 
with the argument "adapter" or "adapter_unsynced".  Wireshark doesn't currently support it; I don't know whether any 
programs other than tcpdump do.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers