Re: How much we can trust packet timestamping

[Werner Almesberger <wa@almesberger.net>]

Alan Cox wrote:
> The packet can be timestamped by the hardware receiving as well as by
> the kernel netif_rx code. This is actually intentional and there is
> hardware that supports doing IRQ raise time sampling which the driver
> can then use to get very accurate data.

By the way, the group of Darryl Veitch have done some extremely
interesting work with high-resolution timestamps, in particular
using the TSC on recent ia32:

http://www.cubinlab.ee.mu.oz.au/probing/
http://www.cubinlab.ee.mu.oz.au/~darryl/tscclock_final.pdf.gz

One general issue in this area is what we can do with time
sources that aren't system-wide, e.g. NIC-local timers. The
problem is to calibrate them and to synchronize them to
wall-clock time. I think there are basically two possible
approaches:

 1) driver gives time synchronization system (in user-space)
    access to "raw" running timer value. Timestamps are also
    "raw" timer values, plus a time source ID, which can then
    be used to convert the values to wall-clock time.

 2) user space pushes exact time to kernel space, which then
    does all the math. Timestamps are already converted to
    wall-clock time.

2) is essentially what we can do with today's interfaces (an
event notifier would be useful, though). The big drawback is
that non-trivial math would have to be done in kernel space.
1) is much easier on the kernel, but has the issue of
requiring some API to get time values and time source
characteristics (time representation, range, etc.).

I'm leaning towards solution 1), because it keeps things simple
for the kernel. But perhaps the best approach is to simply
implement both, and then compare ...

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/