linuxptp-users — Open discussion on using the linuxptp software.

[Linuxptp-users] Using ptp4l on wireless device

[Julian S. <ju...@ju...>]

Hi,

I am trying to migrate from ptp2 to ptp4l currently. Using wired 
networking I got everything to work quite well using software 
timestamping yet and get very good results. But I also need sync via 
wifi (I am aware the results will not be as good as via cable, but 
through ptp2 I was able to achieve at least 100us accuracy).
Now it seems that the wifi stack in recent linux kernels is not 
supporting SOF_TIMESTAMPING_TX_SOFTWARE at all. But this seems to be a 
hard requirement for using ptp4l with software timestamping, right?
I am just wondering how ptp4l was running on a wireless device in this 
discussion:
http://permalink.gmane.org/gmane.comp.linux.ptp.user/295

I'd be glad about any hints how to get ptp4l working with a wireless 
device. Actually I am using a rtl8192cu device right now.
Are there some kernel patches around implementing 
SOF_TIMESTAMPING_TX_SOFTWARE for wireless devices maybe?

-Julian

Re: [Linuxptp-users] Boundary Clock with single MAC

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

On Thu, Oct 23, 2014 at 03:12:45PM +0000, Reto Hermann wrote:
> My
> question is now: Does the driver support such a setup or does the
> recalibrate() function assume that all PHYs use the same reference
> clock, as it is suggested in AN-1838
> (http://www.ti.com/lit/an/snla104a/snla104a.pdf) from TI.

The driver does match the application note.

However, you can probably hack the clock setup that you need into the
driver. You just need to make sure the clocks are ready before the
calibration function gets called.

Good luck,
Richard

Re: [Linuxptp-users] Boundary Clock with single MAC

[Reto H. <ret...@ki...>]

Hello Richard,
thank you very much for your quick reply! I have an additional question regarding the use of the DP83640 driver together with multiple PHYs:  Unfortunately in my hardware-setup each PHY has its own 25MHz crystal reference clock. The good news is, that the PTP clock input/outputs are wired together, so one PHY could output the PTP clock and the other PHYs can use this clock as PTP reference. My question is now: Does the driver support such a setup or does the recalibrate() function assume that all PHYs use the same reference clock, as it is suggested in AN-1838 (http://www.ti.com/lit/an/snla104a/snla104a.pdf) from TI.

Best regards
Reto

-----Ursprüngliche Nachricht-----
Von: Richard Cochran [mailto:ric...@gm...] 
Gesendet: Mittwoch, 22. Oktober 2014 19:55
An: Hermann Reto
Cc: 'lin...@li...'
Betreff: Re: [Linuxptp-users] Boundary Clock with single MAC

On Wed, Oct 22, 2014 at 01:55:00PM +0000, Reto Hermann wrote:
> We have an ARM Cortex A8 Processor (AM3359) with an internal
> hardware Ethernet switch. One of the switch ports is connected with
> the CPU and two ports of that switch are connected to two external
> PHYs (DP83640). Both PHYs are connected to the same MDIO bus. The
> aim of this setup is, that our devices (A and B) behave like a
> PTP-Ethernet-switch using hardware time-stamping in the PHYs and
> implement an BC (or even better an PTP v2 TC)

Coincidentally I am working on a PTP Hardware Clock driver for a
switch with a similar setup.

> [http://kiwaglxswd06.ch.int.kistler.com/wiki/swd/images/1/1a/PTP_HW.jpg]

Sorry, server not found.

> >From the CPU point of view, there is only one Ethernet MAC /
> Interface because the Ethernet switch is implemented as hardware
> module. The PHYs can be accessed separately using the MDIO bus.
> Questions:
> 
> (1) Is it possible to use the Linux PTP Project to implement a
> Boundary Clock with this hardware setup or would that require two
> independent MAC interfaces?

You need two interfaces. Linux already has drivers for the
"Distributed Switch Architecture" (DSA), where each external switch
port appears as a seperate interface on the host CPU.

If your switch supports DSA or similar, then if you take care that the
phydev driver of the DSA interfaces is the dp83640, then it might just
work.

But you will need to do some driver work. It may also be tricky to get
the switch to properly tag and forward the PTP frames to and from the
host CPU.

> (2) DP83640 Driver: I found several comments that the GPIOs of the
> PHYs should be connected together on order to be able to synchronize
> the two PHYs (recalibrate) but I did't find the detail information
> which GPIO of PHY 1should be connected to which GPIO of PHY 2.

If does not matter which GPIO. You can choose any one of these.

	1, 2, 3, 4, 8, 9, 10, 11

The dp83640 driver has a module parameter that lets you configure
this.

HTH,
Richard

Re: [Linuxptp-users] Boundary Clock with single MAC

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

On Wed, Oct 22, 2014 at 01:55:00PM +0000, Reto Hermann wrote:
> We have an ARM Cortex A8 Processor (AM3359) with an internal
> hardware Ethernet switch. One of the switch ports is connected with
> the CPU and two ports of that switch are connected to two external
> PHYs (DP83640). Both PHYs are connected to the same MDIO bus. The
> aim of this setup is, that our devices (A and B) behave like a
> PTP-Ethernet-switch using hardware time-stamping in the PHYs and
> implement an BC (or even better an PTP v2 TC)

Coincidentally I am working on a PTP Hardware Clock driver for a
switch with a similar setup.

> [http://kiwaglxswd06.ch.int.kistler.com/wiki/swd/images/1/1a/PTP_HW.jpg]

Sorry, server not found.

> >From the CPU point of view, there is only one Ethernet MAC /
> Interface because the Ethernet switch is implemented as hardware
> module. The PHYs can be accessed separately using the MDIO bus.
> Questions:
> 
> (1) Is it possible to use the Linux PTP Project to implement a
> Boundary Clock with this hardware setup or would that require two
> independent MAC interfaces?

You need two interfaces. Linux already has drivers for the
"Distributed Switch Architecture" (DSA), where each external switch
port appears as a seperate interface on the host CPU.

If your switch supports DSA or similar, then if you take care that the
phydev driver of the DSA interfaces is the dp83640, then it might just
work.

But you will need to do some driver work. It may also be tricky to get
the switch to properly tag and forward the PTP frames to and from the
host CPU.

> (2) DP83640 Driver: I found several comments that the GPIOs of the
> PHYs should be connected together on order to be able to synchronize
> the two PHYs (recalibrate) but I did't find the detail information
> which GPIO of PHY 1should be connected to which GPIO of PHY 2.

If does not matter which GPIO. You can choose any one of these.

	1, 2, 3, 4, 8, 9, 10, 11

The dp83640 driver has a module parameter that lets you configure
this.

HTH,
Richard

Re: [Linuxptp-users] How to run multiple instances of ptp4l

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

On Mon, Sep 29, 2014 at 01:24:43PM -0400, Rich Schmidt wrote:
> I am attempting to run multiple instances of ptp4l on a PTP slave. The idea
> is that I have an Intel i350-T4 NIC and I want each port to sync to a
> different GrandMaster.  (The slave is an NTP stratum 1 server which would
> sync to multiple GrandMasters, where each GrandMaster is in turn synced to
> an independent time source, like USNO Master Clock1, MC2, MC3...providing
> redundancy for NTP ).    Does this concept require linuxpp operation in
> unicast mode?

If the slave ports (and the GMs) are on separate networks, then there
is no problem, obviously.

If the GMs and the slave ports are all on the same network, then you
can and should use the PTP domainNumber to keep them (virtually)
separate.

HTH,
Richard
 

[Linuxptp-users] How to run multiple instances of ptp4l

[Rich S. <sch...@gm...>]

I am attempting to run multiple instances of ptp4l on a PTP slave. The idea
is that I have an Intel i350-T4 NIC and I want each port to sync to a
different GrandMaster.  (The slave is an NTP stratum 1 server which would
sync to multiple GrandMasters, where each GrandMaster is in turn synced to
an independent time source, like USNO Master Clock1, MC2, MC3...providing
redundancy for NTP ).    Does this concept require linuxpp operation in
unicast mode?  For when I start the second instance of ptp4l, broadcast
mode from the GrandMaster causes PTP confusion on the slave. (Testing with
one GrandMaster feeding each of two PHCs on the slave.)
So I imagine that unicast associations would prevent the slave's ports from
grabbing packets intended for neighboring NICs.
An alternative would be to VLAN the individual ports/GrandMasters, but at
the moment I am testing this using only one GrandMaster for multiple slave
ports.

Thank you,
Rich Schmidt, CTR
US Naval Observatory
Washington, DC

Re: [Linuxptp-users] One-step sync and P2P mode issue

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

On Tue, Sep 02, 2014 at 10:00:13AM +0000, Sriharsha Basavapatna wrote:
> Thanks for the pointer to the flag. But this is still an issue for the driver,
> since it'd have to parse the packet to find that it's a Sync pkt; please
> correct me if I'm missing something here.

Yes, the driver must parse the packets.

This is not an "issue" for driver, but rather simply something that
you have to implement. It isn't hard. See dp83640.c in the Linux
kernel sources.

Thanks,
Richard

Re: [Linuxptp-users] One-step sync and P2P mode issue

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

On Wed, Sep 03, 2014 at 12:29:05AM +0000, Keller, Jacob E wrote:
> 
> I do not know if one-step mode is specific to SYNC packets or should handle any transmit timestamps. Richard, do you know?

One-step is for Sync messages only. The standard also allows one-step
on Pdelay_Resp messages, but this is not implemented in the Linux
kernel, and I don't know of any hardware implementations either.
 
> You may have to check these. At any rate, I believe we already implement packet filters which will do this for you very efficiently.

Right, the BPF can classify packets, but identifying Sync packets
requires a bit more code. See the helper function is_sync() in
drivers/net/phy/dp83640.c in the Linux kernel sources.

Thanks,
Richard

Re: [Linuxptp-users] One-step sync and P2P mode issue

[Sriharsha B. <Sri...@Em...>]

-----Original Message-----
From: Keller, Jacob E [mailto:jac...@in...]
Sent: Wednesday, September 03, 2014 5:59 AM
To: Sriharsha Basavapatna; Richard Cochran
Cc: lin...@li...
Subject: RE: [Linuxptp-users] One-step sync and P2P mode issue



Hi,



> -----Original Message-----

> From: Sriharsha Basavapatna

> [mailto:Sri...@Em...]

> Sent: Tuesday, September 02, 2014 3:00 AM

> To: Richard Cochran

> Cc: Keller, Jacob E; lin...@li...<mailto:lin...@li...>

> Subject: RE: [Linuxptp-users] One-step sync and P2P mode issue

>

> Thanks for the pointer to the flag. But this is still an issue for the

> driver, since it'd have to parse the packet to find that it's a Sync

> pkt; please correct me if I'm missing something here.

>

> The driver saves this flag when it gets the ioctl request. Then at

> transmit completion time the driver would still have to check that the

> flag HWTSTAMP_TX_ONESTEP_SYNC has been set and it should not queue the

> packet in the error queue if it's a Sync pkt. For other packets say

> Delay Request it should still continue to queue the pkt in error

> queue.

>

> For example, here's the pseudo code. Before checking the msg type

> below, the driver would have to parse the packet to find that it's a

> PTP Sync msg(in a raw Ethernet frame or UDP/IPv4/IPV6 pkt).

>



I do not know if one-step mode is specific to SYNC packets or should handle any transmit timestamps. Richard, do you know?



>> I believe it is specific to SYNC packets only in this context; at least

>> w.r.t the flag HWTSTAMP_TX_ONESTEP_SYNC.



You may have to check these. At any rate, I believe we already implement packet filters which will do this for you very efficiently.



>> It'd be better if we can avoid this condition itself, which requires packet

>> filtering.



In the one-step case, you will configure hardware to directly insert the timestamp into the packet buffer as it transmits it



>> HW inserts the timestamp (see my earlier email with details). And provides a

>> copy of timestamp to driver. The driver has been asked by the stack to give

>> a copy of the transmitted packet via the error queue, as clearly indicated

>> by skb->tx_flags: SKBTX_HW_TSTAMP. But the driver has to make an exception

>> just for the 1-step Sync packet and to know that it's a 1-step Sync, it has

>> to parse the packet.



Thanks,

-Harsha



In the other case, you configure hardware to notify driver of the timestamp, and then return it via skb_tstamp_tx



I do actually believe that one-step works for any PTP transmitted timestamp, and if you enable TX_ONESTEP_SYNC that you actually have to do this for all packets, but I honestly cannot remember.



Regards,

Jake



>         if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP &&

>             (ptp_msg->type != MSG_SYNC ||

>             (dev-inst->ptp_flags & HWTSTAMP_TX_ONESTEP_SYNC) == 0)) {

>

>                 /* add skb to error queue */

>

>         }

>

> Thanks,

> -Harsha

Re: [Linuxptp-users] One-step sync and P2P mode issue

[Keller, J. E <jac...@in...>]

Hi,

> -----Original Message-----
> From: Sriharsha Basavapatna
> [mailto:Sri...@Em...]
> Sent: Tuesday, September 02, 2014 3:00 AM
> To: Richard Cochran
> Cc: Keller, Jacob E; lin...@li...
> Subject: RE: [Linuxptp-users] One-step sync and P2P mode issue
> 
> Thanks for the pointer to the flag. But this is still an issue for the driver,
> since it'd have to parse the packet to find that it's a Sync pkt; please
> correct me if I'm missing something here.
> 
> The driver saves this flag when it gets the ioctl request. Then at transmit
> completion time the driver would still have to check that the flag
> HWTSTAMP_TX_ONESTEP_SYNC has been set and it should not queue the
> packet in
> the error queue if it's a Sync pkt. For other packets say Delay Request it
> should still continue to queue the pkt in error queue.
> 
> For example, here's the pseudo code. Before checking the msg type
> below, the
> driver would have to parse the packet to find that it's a PTP Sync msg(in a
> raw
> Ethernet frame or UDP/IPv4/IPV6 pkt).
> 

I do not know if one-step mode is specific to SYNC packets or should handle any transmit timestamps. Richard, do you know?

You may have to check these. At any rate, I believe we already implement packet filters which will do this for you very efficiently.

In the one-step case, you will configure hardware to directly insert the timestamp into the packet buffer as it transmits it

In the other case, you configure hardware to notify driver of the timestamp, and then return it via skb_tstamp_tx

I do actually believe that one-step works for any PTP transmitted timestamp, and if you enable TX_ONESTEP_SYNC that you actually have to do this for all packets, but I honestly cannot remember.

Regards,
Jake

>         if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP &&
>             (ptp_msg->type != MSG_SYNC ||
>             (dev-inst->ptp_flags & HWTSTAMP_TX_ONESTEP_SYNC) == 0)) {
> 
>                 /* add skb to error queue */
> 
>         }
> 
> Thanks,
> -Harsha

Re: [Linuxptp-users] One-step sync and P2P mode issue

[Sriharsha B. <Sri...@Em...>]

Thanks for the pointer to the flag. But this is still an issue for the driver,
since it'd have to parse the packet to find that it's a Sync pkt; please
correct me if I'm missing something here.

The driver saves this flag when it gets the ioctl request. Then at transmit
completion time the driver would still have to check that the flag
HWTSTAMP_TX_ONESTEP_SYNC has been set and it should not queue the packet in
the error queue if it's a Sync pkt. For other packets say Delay Request it
should still continue to queue the pkt in error queue.

For example, here's the pseudo code. Before checking the msg type below, the
driver would have to parse the packet to find that it's a PTP Sync msg(in a raw
Ethernet frame or UDP/IPv4/IPV6 pkt).

        if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP &&
            (ptp_msg->type != MSG_SYNC ||
            (dev-inst->ptp_flags & HWTSTAMP_TX_ONESTEP_SYNC) == 0)) {

                /* add skb to error queue */

        }

Thanks,
-Harsha

-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...] 
Sent: Thursday, August 14, 2014 1:32 PM
To: Sriharsha Basavapatna
Cc: Keller, Jacob E; lin...@li...
Subject: Re: [Linuxptp-users] One-step sync and P2P mode issue

On Thu, Aug 14, 2014 at 06:07:29AM +0000, Sriharsha Basavapatna wrote:
> May be I didn't explain it clearly earlier.
> 
> I understand one-step mode is where HW support is needed and our 
> hardware does insert the timestamp. But because the protocol stack 
> sets the SKBTX_HW_TSTAMP bit in the skb, the driver (which is supposed 
> to return the tx timestamp back up the stack based on this flag) can't 
> distinguish this as a special case for

Yes, it can.

	/*
	 * Enables time stamping for outgoing packets just as
	 * HWTSTAMP_TX_ON does, but also enables time stamp insertion
	 * directly into Sync packets. In this case, transmitted Sync
	 * packets will not received a time stamp via the socket error
	 * queue.
	 */
	HWTSTAMP_TX_ONESTEP_SYNC,

Thanks,
Richard

Re: [Linuxptp-users] One-step sync and P2P mode issue

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

On Thu, Aug 14, 2014 at 06:07:29AM +0000, Sriharsha Basavapatna wrote:
> May be I didn't explain it clearly earlier.
> 
> I understand one-step mode is where HW support is needed and our hardware does
> insert the timestamp. But because the protocol stack sets the SKBTX_HW_TSTAMP
> bit in the skb, the driver (which is supposed to return the tx timestamp back
> up the stack based on this flag) can't distinguish this as a special case for

Yes, it can.

	/*
	 * Enables time stamping for outgoing packets just as
	 * HWTSTAMP_TX_ON does, but also enables time stamp insertion
	 * directly into Sync packets. In this case, transmitted Sync
	 * packets will not received a time stamp via the socket error
	 * queue.
	 */
	HWTSTAMP_TX_ONESTEP_SYNC,

Thanks,
Richard

Re: [Linuxptp-users] One-step sync and P2P mode issue

[Sriharsha B. <Sri...@Em...>]

May be I didn't explain it clearly earlier.

I understand one-step mode is where HW support is needed and our hardware does
insert the timestamp. But because the protocol stack sets the SKBTX_HW_TSTAMP
bit in the skb, the driver (which is supposed to return the tx timestamp back
up the stack based on this flag) can't distinguish this as a special case for
which though the flag is set, it should *not* put a copy of the pkt back on the
error queue.

Here's the sequence:

	1. ptp4l sends down 1-Step sync packet on the event socket (i.e, one
	    for which SO_TIMESTAMPING socket option is set).
	2.  Network stack sets the SKBTX_HW_TSTAMP in skb since socket is
	    marked for SO_TIMESTAMPING.
	3. Stack sends down the skb to driver with SKBTX_HW_TSTAMP set.
	4. Driver sends down the packet to HW.
	5. HW inserts timestamp (yes, it is HW that's inserting, not driver !!).
	6. HW transmits the packet and generates a completion to driver.
	7. The driver looks up the corresponding skb and since SKBTX_HW_TSTAMP
	    is set, makes a copy of skb into error queue.

It is the SKBTX_HW_TSTAMP flag that tells the driver whether it should or
shouldn't pass back a copy of pkt into error queue. In this case, the HW is
working correctly, both inserting the timestamp and providing that inserted
timestamp back to driver. But the driver's decision to pass it back up, is
based on the SKBTX_HW_TSTAMP flag which is driven by ptp4l and the stack. The
reason this flag is set is because ptp4l sent down the skb on a socket that is
marked for HW timestamp insertion/generation.

We could change the driver to make an exception and ignore the flag
SKBTX_HW_TSTAMP and not put a skb back into the error queue, if it's one-step
sync packet that got transmitted. But that doesn't seem like the right approach
as the driver ends up not honoring what the stack is asking it via the flag.
The driver essentially violates the driver "interface" with the stack.

This is why I think that the right way to fix this would be:

1. SKBTX_HW_TSTAMP should not be set on the skb if a copy of skb with
   tx-timestamp is not needed by the consumer. HW would still insert the
   timestamp in the packet while transmitting. But the driver won't copy into
   error queue since SKBTX_HW_TSTAMP is not set in skb.

        OR

2. If the consumer sets the flag SKBTX_HW_TSTAMP, then the consumer should be
   prepared to get a copy of the packet and read it.

I feel that approach 2 is better since SKBTX_HW_TSTAMP implies both inserting
a timestamp and getting back a copy with the timestamp in it.

But the setting of the flag on the skb/pkt is driven by ptp4l. Once that's set,
driver is supposed to take expected action. Like I already said in my previous
email this is also as per the kernel documentation.

Let me know if you still think it's something the driver should workaround.

Thanks,
-Harsha

-----Original Message-----
From: Keller, Jacob E [mailto:jac...@in...] 
Sent: Wednesday, August 13, 2014 11:27 PM
To: Sriharsha Basavapatna
Cc: lin...@li...
Subject: Re: [Linuxptp-users] One-step sync and P2P mode issue

On Wed, 2014-08-13 at 04:21 +0000, Sriharsha Basavapatna wrote:
> 
> -----Original Message-----
> From: Keller, Jacob E [mailto:jac...@in...]
> Sent: Wednesday, August 13, 2014 1:35 AM
> To: lin...@li...
> Subject: Re: [Linuxptp-users] One-step sync and P2P mode issue
> 
> On Tue, 2014-08-12 at 06:46 +0000, Sriharsha Basavapatna wrote:
> > Hi folks,
> > 
> >  
> > 
> > I'm running into this problem in P2P mode with our PTP capable NIC.
> > I'd
> > 
> > appreciate if you could take a look at the details below and confirm 
> > if this is
> > 
> > an issue in ptp4l. The linuxptp version is: 1.4-00060-g93b7807.
> > 
> >  
> > 
> > After starting ptp4l, it fails to send sync after a few iterations 
> > right at
> > 
> > the beginning. The error is "No message of desired type" (ENOMSG - 
> > 42). After
> > 
> > a timeout of 16 seconds (fault clear timeout) it restarts and 
> > encounters
> > 
> > the same error and this repeats.
> > 
> >  
> > 
> > Here's the ptp4l command/args used:
> > 
> >         ptp4l -f ptp2.cfg -HPm2 -l7 -i ptp2
> > 
> >  
> > 
> > Note that I've configured one-step sync that seems to be triggering 
> > this error
> > 
> > condition.
> > 
> >  
> > 
> > ptp4l[352396.491]: selected /dev/ptp4 as PTP clock
> > 
> > ptp4l[352396.493]: PI servo: sync interval 1.000 kp 0.700 ki 
> > 0.300000
> > 
> > ptp4l[352396.514]: port 1: INITIALIZING to LISTENING on INITIALIZE
> > 
> > ptp4l[352397.514]: port 1: delay timeout
> > 
> > ptp4l[352397.514]: port 1: sending pdelay req seq(0)
> > 
> >  
> > 
> > ptp4l[352398.514]: port 1: delay timeout
> > 
> > ptp4l[352398.514]: port 1: sending pdelay req seq(1)
> > 
> >  
> > 
> > ptp4l[352398.544]: port 1: setting asCapable
> > 
> > ptp4l[352399.514]: port 1: delay timeout
> > 
> > ptp4l[352399.514]: port 1: sending pdelay req seq(2)
> > 
> >  
> > 
> > ptp4l[352400.514]: port 1: delay timeout
> > 
> > ptp4l[352400.514]: port 1: sending pdelay req seq(3)
> > 
> >  
> > 
> > ptp4l[352401.514]: port 1: delay timeout
> > 
> > ptp4l[352401.514]: port 1: sending pdelay req seq(4)
> > 
> >  
> > 
> > ptp4l[352402.514]: port 1: delay timeout
> > 
> > ptp4l[352402.515]: port 1: sending pdelay req seq(5)
> > 
> >  
> > 
> > ptp4l[352403.160]: port 1: announce timeout
> > 
> > ptp4l[352403.160]: port 1: LISTENING to MASTER on 
> > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> > 
> > ptp4l[352403.161]: selected best master clock 0090fa.fffe.6c024e
> > 
> > ptp4l[352403.161]: assuming the grand master role
> > 
> > ptp4l[352403.162]: port 1: master tx announce timeout
> > 
> > ptp4l[352403.515]: port 1: delay timeout
> > 
> > ptp4l[352403.515]: port 1: sending pdelay req seq(6)
> > 
> >  
> > 
> > ptp4l[352404.161]: port 1: master sync timeout
> > 
> > ptp4l[352404.161]: p->timestamping (3)
> > 
> >  
> > 
> > ptp4l[352404.515]: port 1: delay timeout
> > 
> > ptp4l[352404.515]: port 1: sending pdelay req seq(7)
> > 
> >  
> > 
> > ptp4l[352405.161]: port 1: master sync timeout
> > 
> > ptp4l[352405.161]: p->timestamping (3)
> > 
> >  
> > 
> > ptp4l[352405.162]: port 1: master tx announce timeout
> > 
> > ptp4l[352405.515]: port 1: delay timeout
> > 
> > ptp4l[352405.515]: port 1: sending pdelay req seq(8)
> > 
> >  
> > 
> > ptp4l[352406.161]: port 1: master sync timeout
> > 
> > ptp4l[352406.161]: send failed: 42 No message of desired type
> > 
> > ptp4l[352406.161]: port 1: send sync failed
> > 
> > ptp4l[352406.161]: port 1: MASTER to FAULTY on FAULT_DETECTED
> > (FT_UNSPECIFIED)
> > 
> > ptp4l[352406.183]: waiting 2^{4} seconds to clear fault on port 1
> > 
> > ptp4l[352422.183]: clearing fault on port 1
> > 
> >  
> > 
> > Based on further debugging, the sequence of events leading to the 
> > error is
> > 
> > shown below:
> > 
> >  
> > 
> > - Driver/HW receives pdelay request and sync msgs alternately like
> > this:
> > 
> >         - pdelay-req
> > 
> >         - sync
> > 
> >         - pdelay-req
> > 
> >         - sync          <----- hits ENOMSG error
> > 
> > - Messages are sent and tx timestamps generated for each (all are 
> > event msgs).
> > 
> > - Driver makes a copy of skb with timestamp info into socket error 
> > queue.
> > 
> 
> I don't think we should even put a message into the socket error queue in the first place if the transmit type was ONESTEP. That might be a driver bug? The driver should be modifying the PTP packet and inserting the timestamp payload for us, without then further notifying the stack.
> 
> If we are in ONESTEP mode, and the driver supports it, then the driver should no longer be sending the timestamp clone back up the stack.
> 
> Thanks,
> Jake
> 
> 
> This would mean that the driver needs to inspect packets in the 
> transmit path to determine if it's 1) a PTP pkt, 2) Sync pkt and 3) 
> One-step flag is set. I feel this is more work in the driver and also 
> I don't see this specified as a requirement for driver support, in the 
> kernel documentation for PTP (Documentation/ 
> networking/timestamping.txt). The only information that the 
> kernel/stack provides to the driver is whether timestamp should be 
> generated for a packet, through SKBTX_HW_TSTAMP in skb_shinfo(skb)->tx_flags. This is the only check that the driver is expected to do.
> 
> I looked at a couple of other drivers and they don't seem to have any 
> such extra checking to filter out error queue insertion of one-step 
> sync. The problem might show up with other drivers. So I think it'd be 
> better to filter it out in ptp4l by just reading back the packet in 
> error queue and dropping/ignoring it.
> 
> Thanks,
> -Harsha

That is exactly what it means. You cannot support one-step mode unless hardware supports it. One-step mode is where the hardware inserts the hardware timestamp into the packet just before sending it with as close accuracy as possible.

There is nothing to filter, or deal with because they simply do not call skb_tx_tstamp. In the case of one-step there is no returned timestamp.

If you use the ONESTEP mode of the hwtstamp ioctl, that is where you inform that all timestamped packets will be onestep mode.

Do any of those drivers you looked at actually support Onestep mode?

One-step mode is a specialized mode which requires hardware support.

It is not better to filter the packet out because it is a bug. The hardware/driver in question needs to be inserting the timestamp directly into the payload of the Sync packet it is timestamping. (else it's not "one step" mode).

If ptp4l silently ignored this packet it would make it harder to find the bug. In addition, if the hardware isn't inserting the timestamp directly into the packet and instead is passing it up the stack it won't work anyways!

Thanks,
Jake

Re: [Linuxptp-users] ptp4l output messages/statistics

[Daniel Le <dan...@ex...>]

Thanks a lot. I change the master's sync interval to be 1 second or longer and see the master offsets are logged instead of rms values.

Daniel

-----Original Message-----
From: Miroslav Lichvar [mailto:mli...@re...] 
Sent: Wednesday, August 13, 2014 4:25 AM
To: Daniel Le
Cc: lin...@li...
Subject: Re: [Linuxptp-users] ptp4l output messages/statistics

On Mon, Aug 11, 2014 at 10:29:01PM +0000, Daniel Le wrote:
> Hi everyone,
> 
> I use the command "ptp4l -m -q -i eth1 -s -S" to test my PTP device in slave mode and with software time stamping. It is connected back-to-back with a grandmaster clock.
> 
> >From the ptp4l output, the last state change message "UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED" indicates successful synchronization with the PTP master clock and the statistics are printed out. However, I don't see the messages about the calculated offset from master, for example "ptp4l[1821225.525]: master offset 17756  s2   adj +1812   path delay 53581", do they only apply to hardware time stamping? If that is the case then which one of the shown statistics is equivalent to "master offset", otherwise what did I miss?

The individual measurements are replaced in the log with the rms values when the sync interval is shorter than summary_interval (1 second by default). See the summary_interval description in the ptp4l man page.

--
Miroslav Lichvar

Re: [Linuxptp-users] One-step sync and P2P mode issue

[Keller, J. E <jac...@in...>]

On Wed, 2014-08-13 at 04:21 +0000, Sriharsha Basavapatna wrote:
> 
> -----Original Message-----
> From: Keller, Jacob E [mailto:jac...@in...] 
> Sent: Wednesday, August 13, 2014 1:35 AM
> To: lin...@li...
> Subject: Re: [Linuxptp-users] One-step sync and P2P mode issue
> 
> On Tue, 2014-08-12 at 06:46 +0000, Sriharsha Basavapatna wrote:
> > Hi folks,
> > 
> >  
> > 
> > I'm running into this problem in P2P mode with our PTP capable NIC.
> > I'd
> > 
> > appreciate if you could take a look at the details below and confirm 
> > if this is
> > 
> > an issue in ptp4l. The linuxptp version is: 1.4-00060-g93b7807.
> > 
> >  
> > 
> > After starting ptp4l, it fails to send sync after a few iterations 
> > right at
> > 
> > the beginning. The error is "No message of desired type" (ENOMSG - 
> > 42). After
> > 
> > a timeout of 16 seconds (fault clear timeout) it restarts and 
> > encounters
> > 
> > the same error and this repeats.
> > 
> >  
> > 
> > Here's the ptp4l command/args used:
> > 
> >         ptp4l -f ptp2.cfg -HPm2 -l7 -i ptp2
> > 
> >  
> > 
> > Note that I've configured one-step sync that seems to be triggering 
> > this error
> > 
> > condition.
> > 
> >  
> > 
> > ptp4l[352396.491]: selected /dev/ptp4 as PTP clock
> > 
> > ptp4l[352396.493]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
> > 
> > ptp4l[352396.514]: port 1: INITIALIZING to LISTENING on INITIALIZE
> > 
> > ptp4l[352397.514]: port 1: delay timeout
> > 
> > ptp4l[352397.514]: port 1: sending pdelay req seq(0)
> > 
> >  
> > 
> > ptp4l[352398.514]: port 1: delay timeout
> > 
> > ptp4l[352398.514]: port 1: sending pdelay req seq(1)
> > 
> >  
> > 
> > ptp4l[352398.544]: port 1: setting asCapable
> > 
> > ptp4l[352399.514]: port 1: delay timeout
> > 
> > ptp4l[352399.514]: port 1: sending pdelay req seq(2)
> > 
> >  
> > 
> > ptp4l[352400.514]: port 1: delay timeout
> > 
> > ptp4l[352400.514]: port 1: sending pdelay req seq(3)
> > 
> >  
> > 
> > ptp4l[352401.514]: port 1: delay timeout
> > 
> > ptp4l[352401.514]: port 1: sending pdelay req seq(4)
> > 
> >  
> > 
> > ptp4l[352402.514]: port 1: delay timeout
> > 
> > ptp4l[352402.515]: port 1: sending pdelay req seq(5)
> > 
> >  
> > 
> > ptp4l[352403.160]: port 1: announce timeout
> > 
> > ptp4l[352403.160]: port 1: LISTENING to MASTER on 
> > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> > 
> > ptp4l[352403.161]: selected best master clock 0090fa.fffe.6c024e
> > 
> > ptp4l[352403.161]: assuming the grand master role
> > 
> > ptp4l[352403.162]: port 1: master tx announce timeout
> > 
> > ptp4l[352403.515]: port 1: delay timeout
> > 
> > ptp4l[352403.515]: port 1: sending pdelay req seq(6)
> > 
> >  
> > 
> > ptp4l[352404.161]: port 1: master sync timeout
> > 
> > ptp4l[352404.161]: p->timestamping (3)
> > 
> >  
> > 
> > ptp4l[352404.515]: port 1: delay timeout
> > 
> > ptp4l[352404.515]: port 1: sending pdelay req seq(7)
> > 
> >  
> > 
> > ptp4l[352405.161]: port 1: master sync timeout
> > 
> > ptp4l[352405.161]: p->timestamping (3)
> > 
> >  
> > 
> > ptp4l[352405.162]: port 1: master tx announce timeout
> > 
> > ptp4l[352405.515]: port 1: delay timeout
> > 
> > ptp4l[352405.515]: port 1: sending pdelay req seq(8)
> > 
> >  
> > 
> > ptp4l[352406.161]: port 1: master sync timeout
> > 
> > ptp4l[352406.161]: send failed: 42 No message of desired type
> > 
> > ptp4l[352406.161]: port 1: send sync failed
> > 
> > ptp4l[352406.161]: port 1: MASTER to FAULTY on FAULT_DETECTED
> > (FT_UNSPECIFIED)
> > 
> > ptp4l[352406.183]: waiting 2^{4} seconds to clear fault on port 1
> > 
> > ptp4l[352422.183]: clearing fault on port 1
> > 
> >  
> > 
> > Based on further debugging, the sequence of events leading to the 
> > error is
> > 
> > shown below:
> > 
> >  
> > 
> > - Driver/HW receives pdelay request and sync msgs alternately like
> > this:
> > 
> >         - pdelay-req
> > 
> >         - sync
> > 
> >         - pdelay-req
> > 
> >         - sync          <----- hits ENOMSG error
> > 
> > - Messages are sent and tx timestamps generated for each (all are 
> > event msgs).
> > 
> > - Driver makes a copy of skb with timestamp info into socket error 
> > queue.
> > 
> 
> I don't think we should even put a message into the socket error queue in the first place if the transmit type was ONESTEP. That might be a driver bug? The driver should be modifying the PTP packet and inserting the timestamp payload for us, without then further notifying the stack.
> 
> If we are in ONESTEP mode, and the driver supports it, then the driver should no longer be sending the timestamp clone back up the stack.
> 
> Thanks,
> Jake
> 
> 
> This would mean that the driver needs to inspect packets in the transmit path
> to determine if it's 1) a PTP pkt, 2) Sync pkt and 3) One-step flag is set. I
> feel this is more work in the driver and also I don't see this specified as a
> requirement for driver support, in the kernel documentation for PTP
> (Documentation/ networking/timestamping.txt). The only information that the
> kernel/stack provides to the driver is whether timestamp should be generated
> for a packet, through SKBTX_HW_TSTAMP in skb_shinfo(skb)->tx_flags. This is the
> only check that the driver is expected to do.
> 
> I looked at a couple of other drivers and they don't seem to have any such
> extra checking to filter out error queue insertion of one-step sync. The
> problem might show up with other drivers. So I think it'd be better to filter
> it out in ptp4l by just reading back the packet in error queue and
> dropping/ignoring it.
> 
> Thanks,
> -Harsha

That is exactly what it means. You cannot support one-step mode unless
hardware supports it. One-step mode is where the hardware inserts the
hardware timestamp into the packet just before sending it with as close
accuracy as possible.

There is nothing to filter, or deal with because they simply do not call
skb_tx_tstamp. In the case of one-step there is no returned timestamp.

If you use the ONESTEP mode of the hwtstamp ioctl, that is where you
inform that all timestamped packets will be onestep mode.

Do any of those drivers you looked at actually support Onestep mode?

One-step mode is a specialized mode which requires hardware support.

It is not better to filter the packet out because it is a bug. The
hardware/driver in question needs to be inserting the timestamp directly
into the payload of the Sync packet it is timestamping. (else it's not
"one step" mode).

If ptp4l silently ignored this packet it would make it harder to find
the bug. In addition, if the hardware isn't inserting the timestamp
directly into the packet and instead is passing it up the stack it won't
work anyways!

Thanks,
Jake

Re: [Linuxptp-users] ptp4l output messages/statistics

[Miroslav L. <mli...@re...>]

On Mon, Aug 11, 2014 at 10:29:01PM +0000, Daniel Le wrote:
> Hi everyone,
> 
> I use the command "ptp4l -m -q -i eth1 -s -S" to test my PTP device in slave mode and with software time stamping. It is connected back-to-back with a grandmaster clock.
> 
> >From the ptp4l output, the last state change message "UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED" indicates successful synchronization with the PTP master clock and the statistics are printed out. However, I don't see the messages about the calculated offset from master, for example "ptp4l[1821225.525]: master offset 17756  s2   adj +1812   path delay 53581", do they only apply to hardware time stamping? If that is the case then which one of the shown statistics is equivalent to "master offset", otherwise what did I miss?

The individual measurements are replaced in the log with the rms
values when the sync interval is shorter than summary_interval (1
second by default). See the summary_interval description in the ptp4l
man page.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] One-step sync and P2P mode issue

[Sriharsha B. <Sri...@Em...>]

-----Original Message-----
From: Keller, Jacob E [mailto:jac...@in...] 
Sent: Wednesday, August 13, 2014 1:35 AM
To: lin...@li...
Subject: Re: [Linuxptp-users] One-step sync and P2P mode issue

On Tue, 2014-08-12 at 06:46 +0000, Sriharsha Basavapatna wrote:
> Hi folks,
> 
>  
> 
> I'm running into this problem in P2P mode with our PTP capable NIC.
> I'd
> 
> appreciate if you could take a look at the details below and confirm 
> if this is
> 
> an issue in ptp4l. The linuxptp version is: 1.4-00060-g93b7807.
> 
>  
> 
> After starting ptp4l, it fails to send sync after a few iterations 
> right at
> 
> the beginning. The error is "No message of desired type" (ENOMSG - 
> 42). After
> 
> a timeout of 16 seconds (fault clear timeout) it restarts and 
> encounters
> 
> the same error and this repeats.
> 
>  
> 
> Here's the ptp4l command/args used:
> 
>         ptp4l -f ptp2.cfg -HPm2 -l7 -i ptp2
> 
>  
> 
> Note that I've configured one-step sync that seems to be triggering 
> this error
> 
> condition.
> 
>  
> 
> ptp4l[352396.491]: selected /dev/ptp4 as PTP clock
> 
> ptp4l[352396.493]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
> 
> ptp4l[352396.514]: port 1: INITIALIZING to LISTENING on INITIALIZE
> 
> ptp4l[352397.514]: port 1: delay timeout
> 
> ptp4l[352397.514]: port 1: sending pdelay req seq(0)
> 
>  
> 
> ptp4l[352398.514]: port 1: delay timeout
> 
> ptp4l[352398.514]: port 1: sending pdelay req seq(1)
> 
>  
> 
> ptp4l[352398.544]: port 1: setting asCapable
> 
> ptp4l[352399.514]: port 1: delay timeout
> 
> ptp4l[352399.514]: port 1: sending pdelay req seq(2)
> 
>  
> 
> ptp4l[352400.514]: port 1: delay timeout
> 
> ptp4l[352400.514]: port 1: sending pdelay req seq(3)
> 
>  
> 
> ptp4l[352401.514]: port 1: delay timeout
> 
> ptp4l[352401.514]: port 1: sending pdelay req seq(4)
> 
>  
> 
> ptp4l[352402.514]: port 1: delay timeout
> 
> ptp4l[352402.515]: port 1: sending pdelay req seq(5)
> 
>  
> 
> ptp4l[352403.160]: port 1: announce timeout
> 
> ptp4l[352403.160]: port 1: LISTENING to MASTER on 
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> 
> ptp4l[352403.161]: selected best master clock 0090fa.fffe.6c024e
> 
> ptp4l[352403.161]: assuming the grand master role
> 
> ptp4l[352403.162]: port 1: master tx announce timeout
> 
> ptp4l[352403.515]: port 1: delay timeout
> 
> ptp4l[352403.515]: port 1: sending pdelay req seq(6)
> 
>  
> 
> ptp4l[352404.161]: port 1: master sync timeout
> 
> ptp4l[352404.161]: p->timestamping (3)
> 
>  
> 
> ptp4l[352404.515]: port 1: delay timeout
> 
> ptp4l[352404.515]: port 1: sending pdelay req seq(7)
> 
>  
> 
> ptp4l[352405.161]: port 1: master sync timeout
> 
> ptp4l[352405.161]: p->timestamping (3)
> 
>  
> 
> ptp4l[352405.162]: port 1: master tx announce timeout
> 
> ptp4l[352405.515]: port 1: delay timeout
> 
> ptp4l[352405.515]: port 1: sending pdelay req seq(8)
> 
>  
> 
> ptp4l[352406.161]: port 1: master sync timeout
> 
> ptp4l[352406.161]: send failed: 42 No message of desired type
> 
> ptp4l[352406.161]: port 1: send sync failed
> 
> ptp4l[352406.161]: port 1: MASTER to FAULTY on FAULT_DETECTED
> (FT_UNSPECIFIED)
> 
> ptp4l[352406.183]: waiting 2^{4} seconds to clear fault on port 1
> 
> ptp4l[352422.183]: clearing fault on port 1
> 
>  
> 
> Based on further debugging, the sequence of events leading to the 
> error is
> 
> shown below:
> 
>  
> 
> - Driver/HW receives pdelay request and sync msgs alternately like
> this:
> 
>         - pdelay-req
> 
>         - sync
> 
>         - pdelay-req
> 
>         - sync          <----- hits ENOMSG error
> 
> - Messages are sent and tx timestamps generated for each (all are 
> event msgs).
> 
> - Driver makes a copy of skb with timestamp info into socket error 
> queue.
> 

I don't think we should even put a message into the socket error queue in the first place if the transmit type was ONESTEP. That might be a driver bug? The driver should be modifying the PTP packet and inserting the timestamp payload for us, without then further notifying the stack.

If we are in ONESTEP mode, and the driver supports it, then the driver should no longer be sending the timestamp clone back up the stack.

Thanks,
Jake


This would mean that the driver needs to inspect packets in the transmit path
to determine if it's 1) a PTP pkt, 2) Sync pkt and 3) One-step flag is set. I
feel this is more work in the driver and also I don't see this specified as a
requirement for driver support, in the kernel documentation for PTP
(Documentation/ networking/timestamping.txt). The only information that the
kernel/stack provides to the driver is whether timestamp should be generated
for a packet, through SKBTX_HW_TSTAMP in skb_shinfo(skb)->tx_flags. This is the
only check that the driver is expected to do.

I looked at a couple of other drivers and they don't seem to have any such
extra checking to filter out error queue insertion of one-step sync. The
problem might show up with other drivers. So I think it'd be better to filter
it out in ptp4l by just reading back the packet in error queue and
dropping/ignoring it.

Thanks,
-Harsha

> - The first sync message in the error queue is not consumed by ptp4l.
> 
> - This is because port_tx_sync() calls transport_send() with event set 
> to
> 
>   TRANS_ONESTEP. The transport send routines check the event type to 
> know
> 
>   whether to call sk_receive() after sending the message to get a 
> copy. They do
> 
>   sk_receive() only if event == TRANS_EVENT.
> 
> - In this case since event is TRANS_ONESTEP, there's no call to 
> sk_receive().
> 
> - This leaves the sync msg in socket error queue.
> 
> - Next pdelay-req is sent; driver clones this skb into error queue.
> 
> - ptp4l invokes sk_receive() to get a copy of this pdelay-req.
> 
> - The kernel function sock_recv_errqueue() or ip_recv_error() is 
> invoked.
> 
> - There's a check in those functions to see if there's more skbs in 
> err queue.
> 
> - The kernel function marks the socket in error(sets sk->sk_err) 
> before return.
> 
> - The next sync message is sent down by ptp4l.
> 
> - Stack calls sock_alloc_send_pskb() to get a skb.
> 
> - There, it checks if the socket is in error and returns failure.
> 
> - The second sync send fails.
> 
>  
> 
> Note that the driver decides whether to make a copy into the error 
> queue based
> 
> on SKBTX_HW_TSTAMP. This gets set for packets that are sent down the 
> stack on
> 
> the event socket; i.e, the socket on which setsockopt(SO_TIMESTAMPING) 
> has been
> 
> done. So the driver seems to be correctly handling the packets.
> 
>  
> 
> It looks like a change in ptp4l might be needed to address this. The 
> transport
> 
> send functions (raw_send(), udp_send()...) should be modified to 
> consume the
> 
> error queue skb also for the case when event is TRANS_ONESTEP. They 
> might just
> 
> have to throw away the skb if the timestamp is not of interest since 
> it is
> 
> one-step.
> 
>  
> 
> Thanks,
> 
> -Harsha
> 
> 
> ----------------------------------------------------------------------
> -------- _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users


------------------------------------------------------------------------------
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] One-step sync and P2P mode issue

[Keller, J. E <jac...@in...>]

On Tue, 2014-08-12 at 06:46 +0000, Sriharsha Basavapatna wrote:
> Hi folks,
> 
>  
> 
> I'm running into this problem in P2P mode with our PTP capable NIC.
> I'd
> 
> appreciate if you could take a look at the details below and confirm
> if this is
> 
> an issue in ptp4l. The linuxptp version is: 1.4-00060-g93b7807.
> 
>  
> 
> After starting ptp4l, it fails to send sync after a few iterations
> right at
> 
> the beginning. The error is "No message of desired type" (ENOMSG -
> 42). After
> 
> a timeout of 16 seconds (fault clear timeout) it restarts and
> encounters
> 
> the same error and this repeats.
> 
>  
> 
> Here's the ptp4l command/args used:
> 
>         ptp4l -f ptp2.cfg -HPm2 -l7 -i ptp2
> 
>  
> 
> Note that I've configured one-step sync that seems to be triggering
> this error
> 
> condition.
> 
>  
> 
> ptp4l[352396.491]: selected /dev/ptp4 as PTP clock
> 
> ptp4l[352396.493]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
> 
> ptp4l[352396.514]: port 1: INITIALIZING to LISTENING on INITIALIZE
> 
> ptp4l[352397.514]: port 1: delay timeout
> 
> ptp4l[352397.514]: port 1: sending pdelay req seq(0)
> 
>  
> 
> ptp4l[352398.514]: port 1: delay timeout
> 
> ptp4l[352398.514]: port 1: sending pdelay req seq(1)
> 
>  
> 
> ptp4l[352398.544]: port 1: setting asCapable
> 
> ptp4l[352399.514]: port 1: delay timeout
> 
> ptp4l[352399.514]: port 1: sending pdelay req seq(2)
> 
>  
> 
> ptp4l[352400.514]: port 1: delay timeout
> 
> ptp4l[352400.514]: port 1: sending pdelay req seq(3)
> 
>  
> 
> ptp4l[352401.514]: port 1: delay timeout
> 
> ptp4l[352401.514]: port 1: sending pdelay req seq(4)
> 
>  
> 
> ptp4l[352402.514]: port 1: delay timeout
> 
> ptp4l[352402.515]: port 1: sending pdelay req seq(5)
> 
>  
> 
> ptp4l[352403.160]: port 1: announce timeout
> 
> ptp4l[352403.160]: port 1: LISTENING to MASTER on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> 
> ptp4l[352403.161]: selected best master clock 0090fa.fffe.6c024e
> 
> ptp4l[352403.161]: assuming the grand master role
> 
> ptp4l[352403.162]: port 1: master tx announce timeout
> 
> ptp4l[352403.515]: port 1: delay timeout
> 
> ptp4l[352403.515]: port 1: sending pdelay req seq(6)
> 
>  
> 
> ptp4l[352404.161]: port 1: master sync timeout
> 
> ptp4l[352404.161]: p->timestamping (3)
> 
>  
> 
> ptp4l[352404.515]: port 1: delay timeout
> 
> ptp4l[352404.515]: port 1: sending pdelay req seq(7)
> 
>  
> 
> ptp4l[352405.161]: port 1: master sync timeout
> 
> ptp4l[352405.161]: p->timestamping (3)
> 
>  
> 
> ptp4l[352405.162]: port 1: master tx announce timeout
> 
> ptp4l[352405.515]: port 1: delay timeout
> 
> ptp4l[352405.515]: port 1: sending pdelay req seq(8)
> 
>  
> 
> ptp4l[352406.161]: port 1: master sync timeout
> 
> ptp4l[352406.161]: send failed: 42 No message of desired type
> 
> ptp4l[352406.161]: port 1: send sync failed
> 
> ptp4l[352406.161]: port 1: MASTER to FAULTY on FAULT_DETECTED
> (FT_UNSPECIFIED)
> 
> ptp4l[352406.183]: waiting 2^{4} seconds to clear fault on port 1
> 
> ptp4l[352422.183]: clearing fault on port 1
> 
>  
> 
> Based on further debugging, the sequence of events leading to the
> error is
> 
> shown below:
> 
>  
> 
> - Driver/HW receives pdelay request and sync msgs alternately like
> this:
> 
>         - pdelay-req
> 
>         - sync
> 
>         - pdelay-req
> 
>         - sync          <----- hits ENOMSG error
> 
> - Messages are sent and tx timestamps generated for each (all are
> event msgs).
> 
> - Driver makes a copy of skb with timestamp info into socket error
> queue.
> 

I don't think we should even put a message into the socket error queue
in the first place if the transmit type was ONESTEP. That might be a
driver bug? The driver should be modifying the PTP packet and inserting
the timestamp payload for us, without then further notifying the stack.

If we are in ONESTEP mode, and the driver supports it, then the driver
should no longer be sending the timestamp clone back up the stack.

Thanks,
Jake

> - The first sync message in the error queue is not consumed by ptp4l.
> 
> - This is because port_tx_sync() calls transport_send() with event set
> to
> 
>   TRANS_ONESTEP. The transport send routines check the event type to
> know
> 
>   whether to call sk_receive() after sending the message to get a
> copy. They do
> 
>   sk_receive() only if event == TRANS_EVENT.
> 
> - In this case since event is TRANS_ONESTEP, there's no call to
> sk_receive().
> 
> - This leaves the sync msg in socket error queue.
> 
> - Next pdelay-req is sent; driver clones this skb into error queue.
> 
> - ptp4l invokes sk_receive() to get a copy of this pdelay-req.
> 
> - The kernel function sock_recv_errqueue() or ip_recv_error() is
> invoked.
> 
> - There's a check in those functions to see if there's more skbs in
> err queue.
> 
> - The kernel function marks the socket in error(sets sk->sk_err)
> before return.
> 
> - The next sync message is sent down by ptp4l.
> 
> - Stack calls sock_alloc_send_pskb() to get a skb.
> 
> - There, it checks if the socket is in error and returns failure.
> 
> - The second sync send fails.
> 
>  
> 
> Note that the driver decides whether to make a copy into the error
> queue based
> 
> on SKBTX_HW_TSTAMP. This gets set for packets that are sent down the
> stack on
> 
> the event socket; i.e, the socket on which setsockopt(SO_TIMESTAMPING)
> has been
> 
> done. So the driver seems to be correctly handling the packets.
> 
>  
> 
> It looks like a change in ptp4l might be needed to address this. The
> transport
> 
> send functions (raw_send(), udp_send()...) should be modified to
> consume the
> 
> error queue skb also for the case when event is TRANS_ONESTEP. They
> might just
> 
> have to throw away the skb if the timestamp is not of interest since
> it is
> 
> one-step.
> 
>  
> 
> Thanks,
> 
> -Harsha
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

[Linuxptp-users] One-step sync and P2P mode issue

[Sriharsha B. <Sri...@Em...>]

Hi folks,

I'm running into this problem in P2P mode with our PTP capable NIC. I'd
appreciate if you could take a look at the details below and confirm if this is
an issue in ptp4l. The linuxptp version is: 1.4-00060-g93b7807.

After starting ptp4l, it fails to send sync after a few iterations right at
the beginning. The error is "No message of desired type" (ENOMSG - 42). After
a timeout of 16 seconds (fault clear timeout) it restarts and encounters
the same error and this repeats.

Here's the ptp4l command/args used:
        ptp4l -f ptp2.cfg -HPm2 -l7 -i ptp2

Note that I've configured one-step sync that seems to be triggering this error
condition.

ptp4l[352396.491]: selected /dev/ptp4 as PTP clock
ptp4l[352396.493]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[352396.514]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[352397.514]: port 1: delay timeout
ptp4l[352397.514]: port 1: sending pdelay req seq(0)

ptp4l[352398.514]: port 1: delay timeout
ptp4l[352398.514]: port 1: sending pdelay req seq(1)

ptp4l[352398.544]: port 1: setting asCapable
ptp4l[352399.514]: port 1: delay timeout
ptp4l[352399.514]: port 1: sending pdelay req seq(2)

ptp4l[352400.514]: port 1: delay timeout
ptp4l[352400.514]: port 1: sending pdelay req seq(3)

ptp4l[352401.514]: port 1: delay timeout
ptp4l[352401.514]: port 1: sending pdelay req seq(4)

ptp4l[352402.514]: port 1: delay timeout
ptp4l[352402.515]: port 1: sending pdelay req seq(5)

ptp4l[352403.160]: port 1: announce timeout
ptp4l[352403.160]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[352403.161]: selected best master clock 0090fa.fffe.6c024e
ptp4l[352403.161]: assuming the grand master role
ptp4l[352403.162]: port 1: master tx announce timeout
ptp4l[352403.515]: port 1: delay timeout
ptp4l[352403.515]: port 1: sending pdelay req seq(6)

ptp4l[352404.161]: port 1: master sync timeout
ptp4l[352404.161]: p->timestamping (3)

ptp4l[352404.515]: port 1: delay timeout
ptp4l[352404.515]: port 1: sending pdelay req seq(7)

ptp4l[352405.161]: port 1: master sync timeout
ptp4l[352405.161]: p->timestamping (3)

ptp4l[352405.162]: port 1: master tx announce timeout
ptp4l[352405.515]: port 1: delay timeout
ptp4l[352405.515]: port 1: sending pdelay req seq(8)

ptp4l[352406.161]: port 1: master sync timeout
ptp4l[352406.161]: send failed: 42 No message of desired type
ptp4l[352406.161]: port 1: send sync failed
ptp4l[352406.161]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[352406.183]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[352422.183]: clearing fault on port 1

Based on further debugging, the sequence of events leading to the error is
shown below:

- Driver/HW receives pdelay request and sync msgs alternately like this:
        - pdelay-req
        - sync
        - pdelay-req
        - sync          <----- hits ENOMSG error
- Messages are sent and tx timestamps generated for each (all are event msgs).
- Driver makes a copy of skb with timestamp info into socket error queue.
- The first sync message in the error queue is not consumed by ptp4l.
- This is because port_tx_sync() calls transport_send() with event set to
  TRANS_ONESTEP. The transport send routines check the event type to know
  whether to call sk_receive() after sending the message to get a copy. They do
  sk_receive() only if event == TRANS_EVENT.
- In this case since event is TRANS_ONESTEP, there's no call to sk_receive().
- This leaves the sync msg in socket error queue.
- Next pdelay-req is sent; driver clones this skb into error queue.
- ptp4l invokes sk_receive() to get a copy of this pdelay-req.
- The kernel function sock_recv_errqueue() or ip_recv_error() is invoked.
- There's a check in those functions to see if there's more skbs in err queue.
- The kernel function marks the socket in error(sets sk->sk_err) before return.
- The next sync message is sent down by ptp4l.
- Stack calls sock_alloc_send_pskb() to get a skb.
- There, it checks if the socket is in error and returns failure.
- The second sync send fails.

Note that the driver decides whether to make a copy into the error queue based
on SKBTX_HW_TSTAMP. This gets set for packets that are sent down the stack on
the event socket; i.e, the socket on which setsockopt(SO_TIMESTAMPING) has been
done. So the driver seems to be correctly handling the packets.

It looks like a change in ptp4l might be needed to address this. The transport
send functions (raw_send(), udp_send()...) should be modified to consume the
error queue skb also for the case when event is TRANS_ONESTEP. They might just
have to throw away the skb if the timestamp is not of interest since it is
one-step.

Thanks,
-Harsha

[Linuxptp-users] ptp4l output messages/statistics

[Daniel Le <dan...@ex...>]

Hi everyone,

I use the command "ptp4l -m -q -i eth1 -s -S" to test my PTP device in slave mode and with software time stamping. It is connected back-to-back with a grandmaster clock.

>From the ptp4l output, the last state change message "UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED" indicates successful synchronization with the PTP master clock and the statistics are printed out. However, I don't see the messages about the calculated offset from master, for example "ptp4l[1821225.525]: master offset 17756  s2   adj +1812   path delay 53581", do they only apply to hardware time stamping? If that is the case then which one of the shown statistics is equivalent to "master offset", otherwise what did I miss?

/ #ptp4l -m -q -i eth1 -s -S
ptp4l[889716.134]: port 1: get_ts_info not supported
ptp4l[889716.136]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[889716.136]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[889717.665]: port 1: new foreign master 00b0ae.fffe.02d103-1
ptp4l[889721.665]: selected best master clock 00b0ae.fffe.02d103
ptp4l[889721.665]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[889722.412]: port 1: minimum delay request interval 2^-7
ptp4l[889723.071]: rms 5248496 max 5248784 freq +1000000000 +/-   0 delay  -214 +/-   0
ptp4l[889724.071]: rms 5246874 max 5247280 freq +1000000000 +/-   0 delay  -307 +/-  24
ptp4l[889725.071]: rms 5245931 max 5246144 freq +1000000000 +/-   0 delay   -76 +/-  74
ptp4l[889726.071]: rms 5244709 max 5244730 freq +1000000000 +/-   0 delay  -148 +/- 107
ptp4l[889727.071]: rms 5247721 max 5251322 freq +1000000000 +/-   0 delay   317 +/- 916
ptp4l[889728.071]: rms 5247639 max 5247912 freq +1000000000 +/-   0 delay  -153 +/-  92
ptp4l[889729.071]: rms 5246445 max 5246760 freq +1000000000 +/-   0 delay  -151 +/-  93
ptp4l[889730.071]: rms 5245002 max 5245186 freq +1000000000 +/-   0 delay  -154 +/-  98
ptp4l[889731.071]: rms 5244443 max 5244774 freq +1000000000 +/-   0 delay   -69 +/-  71
ptp4l[889732.071]: rms 5243877 max 5244106 freq +1000000000 +/-   0 delay   -39 +/-  42
ptp4l[889733.071]: rms 5246876 max 5248038 freq +1000000000 +/-   0 delay   314 +/- 712
ptp4l[889734.071]: rms 5245014 max 5245174 freq +1000000000 +/-   0 delay  -137 +/-  69
ptp4l[889735.071]: rms 5244071 max 5244604 freq +1000000000 +/-   0 delay  -115 +/- 114
ptp4l[889736.071]: rms 5243134 max 5243420 freq +1000000000 +/-   0 delay   -92 +/-  80
ptp4l[889737.071]: rms 5241706 max 5242180 freq +1000000000 +/-   0 delay  -159 +/- 111
ptp4l[889738.071]: rms 5243572 max 5246424 freq +1000000000 +/-   0 delay   728 +/- 1022
ptp4l[889739.071]: rms 5243816 max 5244130 freq +1000000000 +/-   0 delay   -80 +/-  72
ptp4l[889740.071]: rms 5242200 max 5242498 freq +1000000000 +/-   0 delay  -158 +/- 116
ptp4l[889741.071]: rms 5240775 max 5241232 freq +1000000000 +/-   0 delay  -151 +/- 118
ptp4l[889742.071]: rms 5239166 max 5239586 freq +1000000000 +/-   0 delay  -198 +/- 113
ptp4l[889743.071]: rms 5240531 max 5242836 freq +1000000000 +/-   0 delay  -107 +/- 247
ptp4l[889744.071]: rms 5242046 max 5242508 freq +550000000 +/- 450000000 delay  -132 +/- 111
ptp4l[889744.571]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[889745.071]: rms 5240142 max 5240624 freq +99348906 +/- 1926 delay  -199 +/- 147
ptp4l[889746.071]: rms 5238484 max 5238688 freq +99341169 +/- 1960 delay  -193 +/- 121
ptp4l[889747.071]: rms 5237306 max 5237758 freq +99333375 +/- 1929 delay  -136 +/- 102

Thanks!
Daniel

Re: [Linuxptp-users] Error accessing /dev/ptp0

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

On Thu, Aug 07, 2014 at 09:41:14PM +0800, Ronex Dicapriyo wrote:
> PTP master/slave is not working while I tried to run it over same host.
                                                          ^^^^^^^^^^^^^^
What? That doesn't make any sense.

> And Can you please suggest How I could run it on two different linux host, Do I need to use some kind of multicast forwarding for that ?

I already told you how to do that.

  ptp4l -i eth0 -m -q     # master
  ptp4l -i eth0 -m -q -s  # slave

> I tried to run PTP master behind, 10.0.0.1/24 and slave behind 10.0.1.1/24 
...
> piface_1 and piface_2 exist on the host, where I am running two linux guest host.

PTP probably won't work in a virtual machine. Try a real machine instead.

Thanks,
Richard

Re: [Linuxptp-users] Error accessing /dev/ptp0

[Ronex D. <ron...@ya...>]

Hello,


1)
PTP master/slave is not working while I tried to run it over same host.

Following messages are displayed repeatedly:


ptp4l[269.788]: sendto failed: No message of desired type
ptp4l[269.789]: port 1: send sync failed
ptp4l[269.789]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[269.861]: driver changed our HWTSTAMP options
ptp4l[269.863]: tx_type   1 not 1
ptp4l[269.863]: rx_filter 1 not 12
ptp4l[269.864]: selected best master clock 169acc.fffe.7d54bd
ptp4l[277.043]: driver changed our HWTSTAMP options
ptp4l[277.046]: tx_type   1 not 1
ptp4l[277.046]: rx_filter 1 not 12
ptp4l[277.047]: selected best master clock 169acc.fffe.7d54bd
ptp4l[284.513]: driver changed our HWTSTAMP options
ptp4l[284.514]: tx_type   1 not 1
ptp4l[284.515]: rx_filter 1 not 12
ptp4l[284.516]: selected best master clock 169acc.fffe.7d54bd
ptp4l[285.796]: driver changed our HWTSTAMP options
ptp4l[285.798]: tx_type   1 not 1
ptp4l[285.798]: rx_filter 1 not 12
ptp4l[285.799]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[290.943]: driver changed our HWTSTAMP options
ptp4l[290.944]: tx_type   1 not 1
ptp4l[290.945]: rx_filter 1 not 12
ptp4l[290.946]: selected best master clock 169acc.fffe.7d54bd



2) 
And Can you please suggest How I could run it on two different linux host, Do I need to use some kind of multicast forwarding for that ?

I tried to run PTP master behind, 10.0.0.1/24 and slave behind 10.0.1.1/24 

+----------------------+         +----------------------+
|  Linux Guest Host-1  |         | Linux Guest Host-2   |
|   __________         |         |   __________         |    
|  |          |        |         |  |          |        |
|  |   eth0   |        |         |  |  eth0    |        |
|  | 10.2.0.2 |        |         |  | 10.1.0.2 |        |
|  |__________|        |         |  |__________|        |
|                      |         |                      |
+---------+------------+         +----------+-----------+
      ____|____                          ___|_____  
     |         |                        |         | 
     |piface_1 |                        | piface_2| 
     |10.2.0.2 |                        |10.2.0.1 |
     |_________|                        |_________|
    


piface_1 and piface_2 exist on the host, where I am running two linux guest host.

Now, I tried to run ptp master on linux guest host-1
./ptp4l -i eth0 -m -q
And ptp slave on linux guest host-2,
./ptp4l -i eth0 -m -s -q

But On wireshark I could see sync, Follow_up messages from master(captured for piface_1) and on slave(captured over piface_2) I could just see IGMP massages,

I think multicast frames from master doesn't reach to the slave.
Am I missing here some configuration ?



Regards,
Ronex 


On Thursday, 7 August 2014 12:38 AM, Richard Cochran <ric...@gm...> wrote:
 


On Thu, Aug 07, 2014 at 01:51:18AM +0800, Ronex Dicapriyo wrote:
> And by `ptp subsystem`, Do you refer "<kernel_source>/drivers/ptp" ?

Yes, some important files for the ptp subsystem are in drivers/ptp,
but there are also drivers there.

Overall it is not as simple you try to make it. When we say "driver"
this can mean an Ethernet MAC driver, a PHY driver, or a PTP Hardware
Clock driver. Also, the core ptp code is mostly in drivers/ptp, but
there are some bits in the core networking code as well.

You have the source. Now go and read it!

> Does it sends ptp messages (like sync, delay etc..) to all the system in local LAN, and all the local IP's(Private and Public ethernet interface present on same host) ?

It sends multicast messages on the given interface.

> Now  How am I supposed to check output, I believe log messages along with wireshark might can help here.

You can use wireshark, sure. But the slave ptp4l program should print
out the current time offset, once per second.

> Does it stops after syncing the time between slave and master device ?

No.

> 3) Is it possible to establish ptp communication on one to one basis, means master sends ptp messages to slave IP,where ptp4l slave application is listening for master IP address ?

Unicast messaging is possible with the protocol, but it is not
implemented in linuxptp.


Thanks,
Richard

Re: [Linuxptp-users] Error accessing /dev/ptp0

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

On Thu, Aug 07, 2014 at 01:51:18AM +0800, Ronex Dicapriyo wrote:
> And by `ptp subsystem`, Do you refer "<kernel_source>/drivers/ptp" ?

Yes, some important files for the ptp subsystem are in drivers/ptp,
but there are also drivers there.

Overall it is not as simple you try to make it. When we say "driver"
this can mean an Ethernet MAC driver, a PHY driver, or a PTP Hardware
Clock driver. Also, the core ptp code is mostly in drivers/ptp, but
there are some bits in the core networking code as well.

You have the source. Now go and read it!

> Does it sends ptp messages (like sync, delay etc..) to all the system in local LAN, and all the local IP's(Private and Public ethernet interface present on same host) ?

It sends multicast messages on the given interface.

> Now  How am I supposed to check output, I believe log messages along with wireshark might can help here.

You can use wireshark, sure. But the slave ptp4l program should print
out the current time offset, once per second.
 
> Does it stops after syncing the time between slave and master device ?

No.
 
> 3) Is it possible to establish ptp communication on one to one basis, means master sends ptp messages to slave IP,where ptp4l slave application is listening for master IP address ?

Unicast messaging is possible with the protocol, but it is not
implemented in linuxptp.

Thanks,
Richard

Re: [Linuxptp-users] Error accessing /dev/ptp0

[Ronex D. <ron...@ya...>]

Hi Richard,

Thanks for the detailed response, Kindly help on the few more queries for the same:

1)

> 1. so_timestamping socket option (user -> network core -> driver)
> 2. ptp clock character device    (user -> chardev -> ptp subsystem -> driver)
> 3. dynamic posix clock           (user -> time core -> ptp subsystem -> driver)

> The second interface is only used to get a handle to a dynamic posix clock. 


Here by using `driver` I believe you referred the network interface driver rather then driver/ptp implementation.
And by `ptp subsystem`, Do you refer "<kernel_source>/drivers/ptp" ?

2) To run ptp4l I have used following command as you have suggested before:
            On the master host:
                ptp4l -m -q -i eth0

Does it sends ptp messages (like sync, delay etc..) to all the system in local LAN, and all the local IP's(Private and Public ethernet interface present on same host) ?
            On the slave host:
                ptp4l -m -q -i eth0 -s

Now  How am I supposed to check output, I believe log messages along with wireshark might can help here.

Does it stops after syncing the time between slave and master device ?

3) Is it possible to establish ptp communication on one to one basis, means master sends ptp messages to slave IP,where ptp4l slave application is listening for master IP address ?



Regards,
Ronex 




On Wednesday, 6 August 2014 9:53 PM, Richard Cochran <ric...@gm...> wrote:
 


On Wed, Aug 06, 2014 at 05:45:04PM +0800, Ronex Dicapriyo wrote:
> Hello,
> 
> I have few queries related to linuxptp, as mentioned below:
> 
> 
> 1) I tried to run ptp4l application using command:
> /home/ptp4l -i eth0 -p eth0 -m -P (ptp master)

You don't need '-p' unless your kernel is older than v3.5.

> If this device is supposed to be created by user then what is the MAJOR/MINOR number for /dev/ptp0 ?
> And which driver manages/handles access to this node ?

Look for 'ptp' in /proc/devices to get the major number. The minor
number is then zero.

Normally udev creates the node automatically. If you are using
busybox, then mdev should also make the node for you. Otherwise, just
create the node by hand using the 'mknod' command.

> 2) I am also not able to understand the basic higher level abstract flow of how this application works ?
> I think linux kernel has its own ptp driver implementation, So From the application does it use the linux user space API/system calls which further calls linux ptp driver functions (<linux_x.x>/drivers/ptp/), from which hardware ptp supported driver's functions are invoked ?
>     ptp4l(linuxptp app) ---> drivers/ptp ---> ethernet_driver_with_ptp_support

Yes, more or less. There are actually three different kernel
interfaces that ptp4l uses:

1. so_timestamping socket option (user -> network core -> driver)
2. ptp clock character device    (user -> chardev -> ptp subsystem -> driver)
3. dynamic posix clock           (user -> time core -> ptp subsystem -> driver)

The second interface is only used to get a handle to a dynamic posix

clock.

In addition, the phc2sys program uses the ioctls from the ptp clock
character device.  See include/uapi/linux/ptp_clock.h in the Linux
kernel source.

HTH,
Richard

Re: [Linuxptp-users] Error accessing /dev/ptp0

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

On Wed, Aug 06, 2014 at 05:45:04PM +0800, Ronex Dicapriyo wrote:
> Hello,
> 
> I have few queries related to linuxptp, as mentioned below:
> 
> 
> 1) I tried to run ptp4l application using command:
> /home/ptp4l -i eth0 -p eth0 -m -P (ptp master)

You don't need '-p' unless your kernel is older than v3.5.

> If this device is supposed to be created by user then what is the MAJOR/MINOR number for /dev/ptp0 ?
> And which driver manages/handles access to this node ?

Look for 'ptp' in /proc/devices to get the major number. The minor
number is then zero.

Normally udev creates the node automatically. If you are using
busybox, then mdev should also make the node for you. Otherwise, just
create the node by hand using the 'mknod' command.
 
> 2) I am also not able to understand the basic higher level abstract flow of how this application works ?
> I think linux kernel has its own ptp driver implementation, So From the application does it use the linux user space API/system calls which further calls linux ptp driver functions (<linux_x.x>/drivers/ptp/), from which hardware ptp supported driver's functions are invoked ?
>     ptp4l(linuxptp app) ---> drivers/ptp ---> ethernet_driver_with_ptp_support

Yes, more or less. There are actually three different kernel
interfaces that ptp4l uses:

1. so_timestamping socket option (user -> network core -> driver)
2. ptp clock character device    (user -> chardev -> ptp subsystem -> driver)
3. dynamic posix clock           (user -> time core -> ptp subsystem -> driver)

The second interface is only used to get a handle to a dynamic posix
clock.

In addition, the phc2sys program uses the ioctls from the ptp clock
character device.  See include/uapi/linux/ptp_clock.h in the Linux
kernel source.

HTH,
Richard