Re: Hardware timestamp ?

[Stephen Donnelly <stephen () endace com>]

On Mon, 2009-03-02 at 12:24 -0600, Pierre Karampournis wrote:
> Guy Harris wrote :
> > On Feb 27, 2009, at 9:03 AM, Pierre KARAMPOURNIS wrote:
> >
> > > I worked on old Linux Kernel versions so I will try the latest ones 
> > > to see
> > > hardware timestamping. So now I have to search for Network cards 
> > > which can
> > > timestamp the packets with nanosecond resolution (Endace DAG cards can
> > > apparently do that)
> >
> > Yes, but they're not regular networking cards, so they won't use that 
> > kernel code path on Linux; they supply packets through their own API, 
> > and that API does provide nanosecond timestamps, which libpcap turns 
> > into microsecond timestamps.
> >
> > If you want a network card that supplies its own timestamps *and* 
> > functions as a regular network adapter rather than a capture-only 
> > adapter, it would need to have a Linux driver that time-stamped the 
> > skbuff containing the packet.  I don't know whether any cards of that 
> > sort exist, or whether they have Linux drivers that do that (if they 
> > have open-source Linux drivers that don't, you could perhaps modify 
> > them to do so).
> >
> > If, as you said, you're planning to capture traffic on a 
> > gigabit-or-faster network, you might *want* a capture-only NIC for 
> > that purpose, in which case the Endace cards would be sufficient.

> I only need to capture data so endace cards should do the job. I will 
> also modify libpcap to keep the original timestamps with nanosecond 
> resolution so I consider the problem "solved".
> I didn't know the Endace devices, I was not searching in that direction, 
> thank you for your help.

Endace DAG cards capture into our Extensible Record Format (ERF) format,
bypassing the kernel, network stack, and libpcap for efficiency. The ERF
format has a high resolution time stamp in units of 2^-32s, or an
ultimate resolution of ~233ps. The actual resolution depends on the link
type; for Gigabit Ethernet it would typically be 2^-26s (~15ns). The ERF
format also provides additional metadata per frame such as which capture
port the apcket was received on, packet loss tracking, packet errors
etc.

Wireshark for example reads ERF format files directly, so conversion via
libpcap is not necessary (and would be less efficient).

Libpcap 1.0 and trunk can perform 'live' captures from DAG cards while
bypassing the kernel. In this case Ethernet ERF records are converted to
libpcap DLT_EN10MB on the fly, which loses time stamp resolution
(libpcap is microsecond only) and other ERF metadata.

Alternatively libpcap can capture into DLT_ERF. This encapsulates the
ERF record within a libpcap record, hence preserving the original time
stamp and metadata. Wireshark can read this pcap DLT and will use the
ERF record information inside in preference to the pcap packet header
information.

Some DAG cards can also transmit packets at specific times. They use the
time stamp from the ERF record to determine when to transmit the packet
in hardware. This allows for very accurate capture and 'replay' of
network traffic. The inter-packet timing is preserved and regenerated
with high accuracy, typically orders of magnitude better than
software-only approaches.

Regards,
Stephen
-- 
-----------------------------------------------------------------------
    Stephen Donnelly BCMS PhD           email: sfd () endace com
    Endace Technology Ltd               phone: +64 7 839 0540
    Hamilton, New Zealand               cell:  +64 21 530 770
-----------------------------------------------------------------------

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.