[Linuxptp-users] Some general questions.

[TheMazzim M <ma...@gm...>]

Greetings,

linuxptp saved the day for our application.  We needed a PTP GM clock in
our underwater vehicle which obviously meant rack-mount,  black-box
solutions were a no-go.

I do have some questions after having observed the behaviors of ptp4l and
phc2sys.

BACKGROUND:
I've configured a generic PC104 stack, Ubuntu 14.04 box, to serve NTP time,
using PTP.  Previous to this new requirement, it acted solely as a stratum
1 NTP clock. The NTP server is synced to an IRIG-B time code. For legacy
reasons, time code travels via IRIG-B throughout the vehicle. There is a
CSAC (free-wheeling when underwater) that generates the IRIG-B.  I know,
why a CSAC producing IRIG-B?? Unfortunately,  the vehicle is both old and
new, and we are sometimes restricted by legacy systems requirements.

I've followed the RedHat Deployment guide (Chapter 23) to configure the
grand master clock.  It was very insightful.  The GM appears to serve time
correctly but there are some aspects that are not clear, so, here comes the
questions:

1) ethtool shows that both hardware and software time stamping are supported
*Time stamping parameters for p4p1:*
*Capabilities:*
*        hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)*
*        software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)*
*        hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)*
*        software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)*
*        software-system-clock (SOF_TIMESTAMPING_SOFTWARE)*
*        hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)*
*PTP Hardware Clock: 0*
*Hardware Transmit Timestamp Modes:*
*        off                   (HWTSTAMP_TX_OFF)*
*        on                    (HWTSTAMP_TX_ON)*
*Hardware Receive Filter Modes:*
*        none                  (HWTSTAMP_FILTER_NONE)*
*        all                   (HWTSTAMP_FILTER_ALL*)

BUT, if I look at the kernel config file for 4.2.0-27-generic Ubuntu 14.04
kernel, I discover that:

# CONFIG_NETWORK_PHY_TIMESTAMPING is not set

Question:  Why is this not consistent with what ethtool reports?? Or are
these actually independent system requirement checks??? The other kernel
requirements are included as modules (CONFIG_PPS, PTP_1588).

2) The igb driver is loaded for the NIC on this PC104. As a result, the ptp
module is loaded as well.  As I understand, this is further evidence that
hardware time stamping is supported??  Yet, the kernel (question 1) appears
not to be compliant??  What am I missing?

3) ptp4l is started via config file (following instructions on Chp 23.8 in
RH Deployment guide)

*[global]*
*verbose 1*
*priority1 127*
*time_stamping hardware*
*# utc_offset 0*
*[p4p1]*

After some time, I see the following "error". What is this trying to tell
me??

*ptp4l[6346.923]: selected /dev/ptp0 as PTP clock*
*ptp4l[6346.925]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE*
*ptp4l[6346.925]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE*
*ptp4l[6354.282]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES*
*ptp4l[6354.282]: selected local clock 000d48.fffe.2b0c46 as best master*
*ptp4l[6354.283]: assuming the grand master role*
*ptp4l[7816.367]: timed out while polling for tx timestamp*
*ptp4l[7816.367]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused
 by a driver bug*
*ptp4l[7816.367]: port 1: send sync failed*
*ptp4l[7816.367]: port 1: MASTER to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)*
*ptp4l[7832.369]: port 1: FAULTY to LISTENING on INIT_COMPLETE*
*ptp4l[7839.779]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES*
*ptp4l[7839.779]: selected local clock 000d48.fffe.2b0c46 as best master*
*ptp4l[7839.779]: assuming the grand master role*


4) NOTE: As instructed by the Deployment Guide, since I would ultimately
like hardware timestamping, I also issue the phc2sys as

*phc2sys -m -c eth3 -s CLOCK_REALTIME -w*

Which outputs:
*phc2sys[20583.688]: p4p1 sys offset       -32 s2 freq  -84541 delay   8096*
*phc2sys[20584.688]: p4p1 sys offset       -45 s2 freq  -84564 delay   8096*
*phc2sys[20585.688]: p4p1 sys offset       -32 s2 freq  -84565 delay   8016*
*phc2sys[20586.689]: p4p1 sys offset         1 s2 freq  -84541 delay   8097*
*phc2sys[20587.689]: p4p1 sys offset       -21 s2 freq  -84563 delay   8017*
*phc2sys[20588.689]: p4p1 sys offset       -67 s2 freq  -84615 delay   8096*
*phc2sys[20589.689]: p4p1 sys offset       -17 s2 freq  -84585 delay   8096*
*phc2sys[20590.690]: p4p1 sys offset        -4 s2 freq  -84577 delay   8096*
*phc2sys[20591.690]: p4p1 sys offset        63 s2 freq  -84512 delay   8097*
*phc2sys[20592.690]: p4p1 sys offset        59 s2 freq  -84497 delay   8097*
*phc2sys[20593.691]: p4p1 sys offset       171 s2 freq  -84367 delay   7985*
*phc2sys[20594.691]: p4p1 sys offset      -147 s2 freq  -84634 delay   8097*
*phc2sys[20595.691]: p4p1 sys offset       -58 s2 freq  -84589 delay   8096*
*phc2sys[20596.692]: p4p1 sys offset       -58 s2 freq  -84606 delay   8097*
*phc2sys[20597.692]: p4p1 sys offset        55 s2 freq  -84511 delay   8017*
*phc2sys[20598.692]: p4p1 sys offset         1 s2 freq  -84548 delay   8081*
*phc2sys[20599.693]: p4p1 sys offset        28 s2 freq  -84521 delay   8081*
*...*
*....*

What are the units of sys offset?? Does this seem like a "healthy"
situation between ptp4l and phc2sys??

5) The PTP time code is needed by custom A/D devices that time tag each
sample with the PTP time.   I've discovered that they do not remove the UTC
offset (37 seconds) as reported by the PTP sync packets when I use hardware
timestamping.  This problem disappears if I use software timestamping. The
manufacturer of the A/D's would look into this "bug".  If I wanted to
continue to use hardware timestamps, could I force a UTC_OFFSET of 0
seconds in the ptp4l config file.???

The confusion stems from the fact that, despite these questions, the system
appears to produce PTP time.  I've switched from software to hardware time
stamping...at least I think I did, with expected results despite the
reported ptp4l error and the kernel parameter inconsistency.

I've capture events on the A/D's, whose time stamps matched perfectly to
the times the CSAC triggered those events (remember, the CSAC also
generated the IRIG-B).

I wanted to know if I am indeed doing everything correctly.
Sorry for the long winded description. Thanks for your time !!!

Marco