Re: hardware timestamping of packets

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

On 13/06/2012 1:06 PM, Vlad Balan wrote:
> Hi Darren,
> 
> On Tue, Jun 12, 2012 at 7:36 PM, Darren Reed <darrenr%netbsd.org@localhost> 
> wrote:
>> 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?
>>
> 
> The Intel card that I looked at returns values in 16ns increments.
> I think the natural resolution would be nanoseconds.

At 16ns, that allows for a packet rate pf 6 million pps?

More pertinent is that this allows for us to "invent" a timestamp.
So if there are 16 packets delivered every 16ns, then we can add
1ns to the timestamp of each packet after the first to represent
the time that they arrived.

>>> 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?
>>
> 
> That works on the receive path, however on the send path we still want
> in some scenarios to know, on the sender machine, when the packet was
> sent. sendmsg does not return information, so we must call recvmsg to
> get the ancillary data. The data is obtained by calling recvmsg on the
> error queue, where the copy of the sent packet, together with the
> ancillary data that tells us when the packet was sent, is waiting to
> be read.

And how do you tie something received with recvmsg() with something sent
via sendmsg()?

Darren