[Dinkar Bhat <dbhat@xxxxxxxxxxxxxxxxxx>]

Thanks for the very detailed reply.  I can see it is quite difficult to 
support onboard timestamp
computation, since it involves low-level driver changes.

My application requirement can be stated simply as follows: Compare the 
received IP packet
time stamp with the timestamp contained within the IP packet that was 
inserted at the source.
The timestamp in the IP packet is very precise and upto nanosecond 
resolution. There is
no notion of accuracy since the timestamp has an arbitrary origin.

The second best solution after hardware timestamping, seems to be about 
using a very precise high
resolution clock on the receiver machine. Although the timestamps on the 
packets
will not correspond exactly to the timestamp when the packet was 
received at the NIC, I assume that
by gathering packets over a long run, I can estimate the statistics of 
the deviation from the exact
time stamp (maybe a normal distribution) and hence compensate for it or 
at least provide an estimate
of the accuracy of measurement (in terms of standard deviation).

With this second solution, there still seems to be an issue. I looked at 
the timestamps reported on
Ethereal and they seem to be upto microsecond precision. Hence, if my 
clock is high precision,
can Ethereal report any better than microseconds?


Guy Harris wrote:

> 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.