On Dec 23, 2003, at 8:27 AM, Dinkar Bhat wrote:
I have seen several mails on packet timestamp resolution, and I have a
related
question.
As I understand it, it is Winpcap/libpcap which timestamps packets,
It's the code in the packet capture mechanism used by libpcap/WinPcap
that timestamps packets.
In some UNIXes, that code is in the network drivers; I think it's
higher up in the networking code path in other UNIXes. In Windows,
that's done by the WinDump driver.
and that essentially is the resolution of the PC clock.
It's the resolution of whatever clock is being used. It might not be
the "PC clock" because it might not be running on a "PC", either in the
sense of machines sold as "personal computers" or in the sense of
"IBM-compatible personal computer". Some of those machines might have
better high-resolution timers than IBM-compatible PCs do - and I think
at least some OSes on more modern IBM-compatible PC's use the RDTSC
instruction, if present on the processor, to get higher-precision time
stamps.
But I have an Gigabit Ethernet
application that requires very accurate times,
There's precision and accuracy; a clock with picosecond resolution, set
to a time that's 1 1/2 hours off, is very precise and very inaccurate.
You probably need both high precision *and* high accuracy. Given that
time stamping isn't done at the instant a packet arrives at the NIC,
even with a high-precision timer you don't get as high accuracy as
you'd probably like.
and I think there are NICs that support onboard
timestamp computation. If I do find such a NIC, then is it possible
somehow to access that
timestamp using Ethereal (instead of the one generated by
libpcap/Winpcap)?
Ethereal has no provisions whatsoever for, when capturing, getting time
stamps from anything other than libpcap/WinPcap.
It's not clear that it even *could* do so, as it does not come with any
NIC drivers; supporting an onboard time stamp clock would require NIC
driver changes, and possibly also changes to the code that the NIC
driver calls in order to supply packets to the packet capture
mechanism. (Ethereal is probably unlikely ever to come with NIC
drivers, unless somebody wants to develop and support special versions
of those drivers (which I don't expect to see happen).
If you're using a free-software UNIX, you'd have to modify the driver
yourself - and figure out the right place to do the time stamping.
Unfortunately, in the BSDs, the time stamping is done in the common BPF
code, so you'd have to change the signature of "bpf_tap()" and/or
"bpf_mtap()" to take an optional time stamp pointer and use that if
supplied, and change all the other drivers you're building into your
kernel to pass a NULL for the time stamp pointer, or provide new
variants of "bpf_tap()" and "bpf_mtap()", with a time stamp argument,
for your driver to use. I don't know offhand where it's done in Linux.
If you're using a commercial UNIX, you might be completely out of luck.
If you're using Windows, you'd have to find some way to pass the time
stamp through NDIS to the WinPcap driver, assuming that's possible,
and, if you could do tha, find out where WinPcap time-stamps the packet
and change it to use that time stamp.