Re: [Linuxptp-users] Software Based Timestamps does not work

[Richard C. <ric...@gm...>]

On Fri, Feb 17, 2012 at 11:38:40PM +0000, Keller, Jacob E wrote:

> When enabling software based timestamps via the '-s' switch, the
> program switches to the faulty state instantly after transmitting a
> packet that should be timestamped because the software timestamp is
> never obtained. With further investigation, it turns out that
> software timestamping appears to be disabled. I tested with the
> kernel timestamping.c program, and indeed just selecting
> sof_timestamping_tx_software, sof_timestamping_rx_software and
> sof_timestamping_software does not return timestamps. The additional
> option of sof_timestampns must also be enabled.

But that gets the time stamp using the legacy BSD loopback method. 
I did not support this in ptp4l because it only works on UDPv4
packets.

> I would like to use
> software timestamping in order to connect ptp4l to a grandmaster
> clock as verification that the protocol implementation works with a
> known good PTP clock.

Background: When Patrick Ohly introduced SO_TIMESTAMPING, the idea was
to support Tx time stamps in a centralized place in the stack, for all
drivers, just like to Rx time stamping. Several kernel crashes later,
he discover that this can only be done in each individual driver.

Presently there are only a dozen or so drivers with this support. I
have a table of them on the linuxptp home page.

So, you need to add one line, skb_tx_timestamp(), into the MAC driver
in order to get ptp4l working with SW timestamping on your hardware.

[ And please then submit a patch to netdev. I am trying to get
  SO_TIMESTAMPING support into every Ethernet driver, but there are
  lots and lots of them. ]

> While the intention is for ptp4l to be used with hardware
> timestamping, there still is issue with software timestamping not
> working (for when the hardware doesn't support offloading)

Yep, but I do consider this a driver issue. Let us work to get
SO_TIMESTAMPING support into the kernel across the board.

Thanks,
Richard