Re: hardware timestamping of packets

[Darren Reed <darrenr%netbsd.org@localhost>]

On 13/06/2012 8:44 AM, Vlad Balan wrote:
...
> First of all, most hardware cards that claim to do timestamping can
> only timestamp a limited number of packets and use filters in order to
> determine which packets to stamp.
...
> When the filter is disabled and all packets are
> timestamped, the registers are no longer locked and the timestamp
> always corresponds to the latest received packet. Therefore if you
> have multiple packets in one interrupt, you only get the hardware
> timestamp of the last one. The only way to go around this (at least
> for the Intel card) is to set a filter that makes most packet arrivals
> create an interrupt, but then capturing at line speed would probably
> not be feasible.

What is the resolution of the time stamp?
Microseconds? Nanoseconds? Picoseconds?
Or is it in some other measure, such as ticks?

> Another issue has to do with the interface when timestamping TX
> packets. Timestamps are returned over the socket as ancillary data,
> which means that they come with the associated packet. Of course, on
> the transmit side there is no incoming packet, so what Linux does is
> to copy the outgoing packet into a third queue associated with each
> socket (the error queue, this seems Linux specific) and attach the
> timestamp as ancillary data to that. This extension is not impossible
> to add to NetBSD, however I wanted to check with you before adding a
> third queue to the sockets. Linux uses a specific flag in recvmsg to
> indicate that it wants a packet from the error queue.

Why wouldn't it be appropriate to use SCM_TIMESTAMP or
something similar to that?

> The third issue has to do with transmitting timestamps associated with
> packets from the driver level to the socket level, where they can be
> transformed into ancillary information to be returned to the users.

I would recommend investigating use of m_tag.

Darren