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

Re: [Linuxptp-users] PTP implementation on AM335x

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

On Mon, Nov 21, 2016 at 02:20:46PM +0800, Hardik Gohil wrote:
> starting from which kernel version support is there ?

Check out the driver support matrix at:

   http://linuxptp.sourceforge.net

There you will find:

    | cpts       | Texas Instruments am335x |     3.8 |

This information is also in the README.org file.

> how to confirm HW time stamping feature ?

ethtool -T is a good start.

HTH,
Richard

Re: [Linuxptp-users] AM571x linuxptp support

[FUSTE E. <emm...@th...>]

Le 19/11/2016 à 21:24, Richard Cochran a écrit :
> On Sat, Nov 19, 2016 at 11:40:03AM -0500, Dale Smith wrote:
>> Interesting.  Do you think it's possible to rewrite the driver to
>> use whatever HW support is available?  Or is the HW so broken that
>> they had to do it in SW?
> The HW PLLs on the am335x are not stable, and so when you dial a
> non-zero frequency adjustment, the clock goes bonkers.  There is no SW
> work around that I am aware of.
>
>> Yeah, if you can't wiggle an I/o pin precisely based of the 1588
>> clock, what's the point of the clock?
> Well, you can synchronize this PHC reasonably well via PTP, and then
> use phc2sys to get the system time globally correct to within a few
> microseconds, so it is not totally useless.  but you are right, it is
> a shame that this HW unit is so poorly designed.
If the HW time stamping and PHC adjustments are working well, this is 
not very fair.
I don't know many socs that support steering their main PLLs during 
normal operations.
Even if the PLLs are not very stable, you could do very very slow 
external adjustments
but you need a non negligible amount  of external HW.

Regards,
Emmanuel.

[Linuxptp-users] PTP implementation on AM335x

[Hardik G. <har...@gm...>]

Hello,

I am working on AM335x running on linux -3.2.0

I want to implement PTP and I have done the following configuration

   1. Select PPS Support - Device Drivers ---> PPS Support ---> <*> PPS
   Support
   2. Select PTP Clock Support - Device Drivers ---> PTP Clock Support --->
   <*> PTP Clock Support
   3. Select TI CPTS PTP Clock - Device Drivers ---> PTP Clock Support --->
   <*> TI CPTS as PTP clock

As per my study AM335x supports Hardware time stamping at MAC layer.

In order to confirm this I am using ethtool.

root@phyCORE-AM335x:~ ./ethtool -T eth0
Time stamping parameters for eth0:
Cannot get device time stamping settings: Operation not supported

starting from which kernel version support is there ?
how to confirm HW time stamping feature ?

Regards,
Hardik A Gohil

Re: [Linuxptp-users] AM571x linuxptp support

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

On Sat, Nov 19, 2016 at 11:40:03AM -0500, Dale Smith wrote:
> Interesting.  Do you think it's possible to rewrite the driver to
> use whatever HW support is available?  Or is the HW so broken that
> they had to do it in SW?

The HW PLLs on the am335x are not stable, and so when you dial a
non-zero frequency adjustment, the clock goes bonkers.  There is no SW
work around that I am aware of.

> Yeah, if you can't wiggle an I/o pin precisely based of the 1588
> clock, what's the point of the clock?

Well, you can synchronize this PHC reasonably well via PTP, and then
use phc2sys to get the system time globally correct to within a few
microseconds, so it is not totally useless.  but you are right, it is
a shame that this HW unit is so poorly designed.

Thanks,
Richard

Re: [Linuxptp-users] AM571x linuxptp support

[Dale S. <dal...@gm...>]

Sent from my iPhone

> On Nov 19, 2016, at 2:23 AM, Richard Cochran <ric...@gm...> wrote:



> The frequency adjustment logic on the am335x is broken.  The driver
> implements frequency adjustment in SW.  So the HW functions are
> useless.

Interesting.  Do you think it's possible to rewrite the driver to use whatever HW support is available?  Or is the HW so broken that they had to do it in SW?


>  Even if the HW frequency worked, still the resolution of the
> capture/compare logic is so coarse as to be 

Yeah, if you can't wiggle an I/o pin precisely based of the 1588 clock, what's the point of the clock?

-Dale

Re: [Linuxptp-users] AM571x linuxptp support

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

On Fri, Nov 18, 2016 at 08:20:22AM -0500, David Cemin wrote:
> thank you for your prompt response. I assume you have tried it on TI AM335x
> then. If that is the case, did you use any specific development kit ?

It works on the BBW and BBB.

> Im
> interested in understanding what kind of external hardware would be
> required for this (i.e. external controlled oscillator).

It works without external HW, but see below.

We don't have any generic kernel support for external VCOs, but you
can hack it in for a particular MAC by changing the PHC driver's
.adjfreq method to steer the VCO instead.

> Also, do you know
> anything about the 1pps output on these devices ?

The frequency adjustment logic on the am335x is broken.  The driver
implements frequency adjustment in SW.  So the HW functions are
useless.  Even if the HW frequency worked, still the resolution of the
capture/compare logic is so coarse as to be unusable, IIRC.

HTH,
Richard

Re: [Linuxptp-users] AM571x linuxptp support

[David C. <dav...@co...>]

Hi Richard,

thank you for your prompt response. I assume you have tried it on TI AM335x
then. If that is the case, did you use any specific development kit ? Im
interested in understanding what kind of external hardware would be
required for this (i.e. external controlled oscillator). Also, do you know
anything about the 1pps output on these devices ?

Thank you

regards

David

On Thu, Nov 17, 2016 at 12:12 PM, Richard Cochran <ric...@gm...>
wrote:

> On Thu, Nov 17, 2016 at 09:36:54AM -0500, David Cemin wrote:
> > The AM571x and AM572x have the same CPTS block and the PTP solution on
> this
> > family of processors is very similar.
> >
> > My question to this list is: How is the support for linuxptp on these
> > processors? Is it fully functional ?
>
> If the cpts driver is enabled via the device tree, then the block
> should work as well on the am57xx as it does on the am335x.  I haven't
> tried it though.
>
> HTH,
> Richard
>
>


-- 

*+1 (343) 777-1735* David Cemin http://coveloz.com


<http://coveloz.com/>

Re: [Linuxptp-users] AM571x linuxptp support

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

On Thu, Nov 17, 2016 at 09:36:54AM -0500, David Cemin wrote:
> The AM571x and AM572x have the same CPTS block and the PTP solution on this
> family of processors is very similar.
> 
> My question to this list is: How is the support for linuxptp on these
> processors? Is it fully functional ?

If the cpts driver is enabled via the device tree, then the block
should work as well on the am57xx as it does on the am335x.  I haven't
tried it though.

HTH,
Richard

[Linuxptp-users] AM571x linuxptp support

[David C. <dav...@co...>]

Hi,

On the project's page I see that there is hardware timestamp support on the
cpts for the TI am335x (code can be found on linux kernel at <linux kernel
3.8+>/drivers/net/ethernet/ti/cpts.c)

The AM571x and AM572x have the same CPTS block and the PTP solution on this
family of processors is very similar.

My question to this list is: How is the support for linuxptp on these
processors? Is it fully functional ?

Thank you

regards,

David

-- 

*+1 (343) 777-1735* David Cemin http://coveloz.com


<http://coveloz.com/>

Re: [Linuxptp-users] Does ptp4l support unicast ?

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

On Tue, Nov 15, 2016 at 09:20:51AM -0500, David Cemin wrote:
> Since it is not supported, do you know if there is anyone working on this
> already ?

Not that I know of.

> If not, do you know what the effort would be to have this support
> implemented within ptp4l ?

I think it would require substantial effort.  It entails implementing
the following options from 1588:

  16.1 Unicast message negotiation
  17.5 Unicast discovery
  17.6 Acceptable master table
       [ Since this is very similar to the unicastMasterTable of 17.5,
         you can kill two birds with one stone. ]

We already have some support for subscriptions and notifications, and
so you would naturally build upon that.

Thanks,
Richard

  

Re: [Linuxptp-users] Does ptp4l support unicast ?

[David C. <dav...@gm...>]

Hi Richard,

Since it is not supported, do you know if there is anyone working on this
already ? If not, do you know what the effort would be to have this support
implemented within ptp4l ?

Thank you

regards,

David

On Sat, Jul 9, 2016 at 2:57 PM, Richard Cochran <ric...@gm...>
wrote:

> On Sun, Jul 10, 2016 at 12:24:28AM +0800, W.F. YANG wrote:
> > Does the ptp4l support ip unicast instead of ip multicast for all
> > transmission, not just for delay request ?
>
> No.
>
> > Besides, is it a portion of ptp protocol standard ?
>
> Yes, unicast is an option within the IEEE 1588 standard.
>
>
> HTH,
> Richard
>
>
>
> ------------------------------------------------------------
> ------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>



-- 
David Cemin
+1 343-777-1735

[Linuxptp-users] FWD: Hardware timestamping does not work

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

This was posted on the linuxptp mailing list possibly highlighting an issue with the igb driver and i219. I thought I would forward it to e1000-devel so that the right people can get a look at it.

Thanks,
Jake

From: Jan Deinhard [mailto:jan...@gm...]
Sent: Sunday, November 06, 2016 10:57 AM
To: lin...@li...
Subject: Re: [Linuxptp-users] Hardware timestamping does not work

Hi Richard,

2016-11-05 20:26 GMT+01:00 Richard Cochran <ric...@gm...<mailto:ric...@gm...>>:
On Sat, Nov 05, 2016 at 04:38:04PM +0100, Jan Deinhard wrote:
> What can I do to find out what the problem is?

I guess that either the imx6 driver is broken by design, or that it is
mis-configured on your board.  I would verify that the input clock to
the time stamping unit is the same frequency as the driver expects, or
if the driver detects the frequency, that this is correct.

You will probably have to dig into the data sheet and into the driver
source.

Here is one simple sanity check for the clock.  Run

  testptp -g; sleep 60; testptp -g

and verify that the difference between the two outputs is about 60
seconds.

The sanity check on the eval board seems ok:

$ ./a.out -f 0; ./a.out -g; sleep 60; ./a.out -g
frequency adjustment okay
clock time: 1478391262.040584932<tel:040584932> or Sun Nov  6 00:14:22 2016
clock time: 1478391322.082633172<tel:082633172> or Sun Nov  6 00:15:22 2016
The difference is 60.04204824<tel:04204824> seconds so I have to check my PC:

$ ./a.out -f 0; ./a.out -g; sleep 60; ./a.out -g
frequency adjustment okay
clock time: 1478445034.316473288 or Sun Nov  6 16:10:34 2016
clock time: 1478445049.319217444 or Sun Nov  6 16:10:49 2016
The difference is 15.002744156 seconds. Ouch!

I guess I have to check the drivers used on my PC or is there anything else I can do here?

Thanks,
Jan

2016-11-05 20:26 GMT+01:00 Richard Cochran <ric...@gm...<mailto:ric...@gm...>>:
On Sat, Nov 05, 2016 at 04:38:04PM +0100, Jan Deinhard wrote:
> I am using a Debian workstation and a i.MX6UL evaluation board running on a
> Linux build with Yocto. According to ethtool -T eth0 both systems support
> PTP hardware timestamping.

...

> ptp4l[26435.632]: master offset 4399753214 s2 freq +32767999 path delay
> -277121915
>
> It is not getting better after some minutes. Master offset is alway
> increasing and freq is always the same value.

The frequency is locked here at maximum offset, and the device is not
converging.  This is most likely a driver or HW problem on the imx6.

> Workstation:
>
> $ uname
> -a
>
> Linux polaris 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
> x86_64 GNU/Linux
>
> $ lspci
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
> I219-V (rev 31)

If this i219 is working with the igb driver, and the driver shows HW
time stamping enabled, then it should work well.  So this isn't the
problem, most likely.

> Eval board:
>
> $ uname -a
> Linux imx6ulevk 4.1.15-2.0.0+gb63f3f5 #1 SMP PREEMPT Wed Nov 2 21:42:19 CET
> 2016 armv7l armv7l armv7l GNU/Linux

I have never tested the ptp driver for the imx6, and I am highly
suspicious of Freescale "quality" drivers.

> What can I do to find out what the problem is?

I guess that either the imx6 driver is broken by design, or that it is
mis-configured on your board.  I would verify that the input clock to
the time stamping unit is the same frequency as the driver expects, or
if the driver detects the frequency, that this is correct.

You will probably have to dig into the data sheet and into the driver
source.

Here is one simple sanity check for the clock.  Run

  testptp -g; sleep 60; testptp -g

and verify that the difference between the two outputs is about 60
seconds.

> Or am I misinterpreting the output?

Looks like a problem on the imx6.  You can run a test between the i219
and any other linux PC (even if that PC only has SW time stamping) in
order to exclude a problem with the i219.

> What does the "freq" value mean?

This is the adjustment in parts per billion.  Normally the magnitute
of this value should never exceed 100 ppm or so.

HTH,
Richard

Re: [Linuxptp-users] [announce] version 1.8 released

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

On Mon, Nov 07, 2016 at 11:36:34AM +0100, Tino Mettler wrote:
> there is no v1.8 git tag on SF:

Fixed it.

Thanks,
Richard

Re: [Linuxptp-users] [announce] version 1.8 released

[Tino M. <tin...@al...>]

On Sun, 2016-11-06 at 21:00 +0100, Richard Cochran wrote:

[...]

> I pushed out the v1.8 tag and a tar ball on SF.

Hi Richard,

there is no v1.8 git tag on SF:

https://sourceforge.net/p/linuxptp/code/ci/master/tree/

Regards,
Tino

[Linuxptp-users] [announce] version 1.8 released

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

Dear linuxptp users and developers,

I released Version 1.8 of linuxptp, just a few months after the
previous release.  Really this is mostly a bug fix release, but we did
sneak in one new feature.  Thanks go to Henry for the link state idea
and to Clyde for the bug report.  I pushed out the v1.8 tag and a tar
ball on SF.

Cheers,
Richard


Richard Cochran (11):
      port: Fix input to the BMC for forming the spanning tree.
      Fix regression in one-step configuration.
      clock: Remove cruft from the creation method.
      rtnl: Introduce RT netlink sockets.
      sk: Add a method to obtain a socket for utility purposes.
      clock: Remove stray semicolon.
      clock: Fix coding style within a helper function.
      clock: Remember each port's interface index.
      port: Provide methods to set and get the link status.
      clock: Monitor the link status using a RT netlink socket.
      Version 1.8

Re: [Linuxptp-users] Software timestamping

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

On Sun, Nov 06, 2016 at 07:30:48PM +0100, Jan Deinhard wrote:
> $ ethtool -T eth0
> Time stamping parameters for eth0:
> Capabilities:
>     software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
>     software-system-clock (SOF_TIMESTAMPING_SOFTWARE)

You are missing:

      software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)

> What is the difference between options -S and -H?

-S gets the time stamps in software in the Linux networking stack.

> What hardware support is needed for option -S?

No special HW support is needed.

> Is it a driver problem?

Yes.  The receive time stamp is handled by the core networking code,
but the transmit time stamp must be done in the driver.  Many, but not
all drivers implement it.

You need to add one line to the transmit path in the driver:

	skb_tx_timestamp(skb);

Quoting include/linux/skbuff.h:

 * skb_tx_timestamp() - Driver hook for transmit timestamping
 *
 * Ethernet MAC Drivers should call this function in their hard_xmit()
 * function immediately before giving the sk_buff to the MAC hardware.
 *
 * Specifically, one should make absolutely sure that this function is
 * called before TX completion of this packet can trigger.  Otherwise
 * the packet could potentially already be freed.

HTH,
Richard

Re: [Linuxptp-users] Hardware timestamping does not work

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

On Sun, Nov 06, 2016 at 07:57:09PM +0100, Jan Deinhard wrote:
> The difference is 15.002744156 seconds. Ouch!
> 
> I guess I have to check the drivers used on my PC or is there anything else
> I can do here?

Ok, so I haven't heard of the i219 before, and somehow the igb driver
is treating it like a i210, but the i219 is obviously different.
You'll have to take this up with Intel.  They do have a mailing list,
e1000-devel.

The test result is pretty clear, and the Intel people are usually
responsive.

Thanks,
Richard

Re: [Linuxptp-users] Hardware timestamping does not work

[Jan D. <jan...@gm...>]

Hi Richard,

2016-11-05 20:26 GMT+01:00 Richard Cochran <ric...@gm...>:

> On Sat, Nov 05, 2016 at 04:38:04PM +0100, Jan Deinhard wrote:
> > What can I do to find out what the problem is?
>
> I guess that either the imx6 driver is broken by design, or that it is
> mis-configured on your board.  I would verify that the input clock to
> the time stamping unit is the same frequency as the driver expects, or
> if the driver detects the frequency, that this is correct.
>
> You will probably have to dig into the data sheet and into the driver
> source.
>
> Here is one simple sanity check for the clock.  Run
>
>   testptp -g; sleep 60; testptp -g
>
> and verify that the difference between the two outputs is about 60
> seconds.
>
>
The sanity check on the eval board seems ok:

$ ./a.out -f 0; ./a.out -g; sleep 60; ./a.out -g
frequency adjustment okay
clock time: 1478391262.040584932 or Sun Nov  6 00:14:22 2016
clock time: 1478391322.082633172 or Sun Nov  6 00:15:22 2016

The difference is 60.04204824 seconds so I have to check my PC:

$ ./a.out -f 0; ./a.out -g; sleep 60; ./a.out -g
frequency adjustment okay
clock time: 1478445034.316473288 or Sun Nov  6 16:10:34 2016
clock time: 1478445049.319217444 or Sun Nov  6 16:10:49 2016

The difference is 15.002744156 seconds. Ouch!

I guess I have to check the drivers used on my PC or is there anything else
I can do here?

Thanks,
Jan

2016-11-05 20:26 GMT+01:00 Richard Cochran <ric...@gm...>:

> On Sat, Nov 05, 2016 at 04:38:04PM +0100, Jan Deinhard wrote:
> > I am using a Debian workstation and a i.MX6UL evaluation board running
> on a
> > Linux build with Yocto. According to ethtool -T eth0 both systems support
> > PTP hardware timestamping.
>
> ...
>
> > ptp4l[26435.632]: master offset 4399753214 s2 freq +32767999 path delay
> > -277121915
> >
> > It is not getting better after some minutes. Master offset is alway
> > increasing and freq is always the same value.
>
> The frequency is locked here at maximum offset, and the device is not
> converging.  This is most likely a driver or HW problem on the imx6.
>
> > Workstation:
> >
> > $ uname
> > -a
> >
> > Linux polaris 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
> > x86_64 GNU/Linux
> >
> > $ lspci
> > 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
> > I219-V (rev 31)
>
> If this i219 is working with the igb driver, and the driver shows HW
> time stamping enabled, then it should work well.  So this isn't the
> problem, most likely.
>
> > Eval board:
> >
> > $ uname -a
> > Linux imx6ulevk 4.1.15-2.0.0+gb63f3f5 #1 SMP PREEMPT Wed Nov 2 21:42:19
> CET
> > 2016 armv7l armv7l armv7l GNU/Linux
>
> I have never tested the ptp driver for the imx6, and I am highly
> suspicious of Freescale "quality" drivers.
>
> > What can I do to find out what the problem is?
>
> I guess that either the imx6 driver is broken by design, or that it is
> mis-configured on your board.  I would verify that the input clock to
> the time stamping unit is the same frequency as the driver expects, or
> if the driver detects the frequency, that this is correct.
>
> You will probably have to dig into the data sheet and into the driver
> source.
>
> Here is one simple sanity check for the clock.  Run
>
>   testptp -g; sleep 60; testptp -g
>
> and verify that the difference between the two outputs is about 60
> seconds.
>
> > Or am I misinterpreting the output?
>
> Looks like a problem on the imx6.  You can run a test between the i219
> and any other linux PC (even if that PC only has SW time stamping) in
> order to exclude a problem with the i219.
>
> > What does the "freq" value mean?
>
> This is the adjustment in parts per billion.  Normally the magnitute
> of this value should never exceed 100 ppm or so.
>
> HTH,
> Richard
>

[Linuxptp-users] Software timestamping

[Jan D. <jan...@gm...>]

Hello,

I'm trying to use ptp4l (Version 1.7) on a Raspberry Pi. Unfortunately the
device's network interface does not support hardware timestamping.

$ ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
    software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
    software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none

I thought I could use software timestamping in this case. Though executing
ptp4l with option -S I see the following output:

$ ./ptp4l -i eth0 -S -m
ptp4l[42.597]: interface 'eth0' does not support requested timestamping mode
failed to create a clock

Obviously my understanding of option -S or software timestamping is wrong.

What is the difference between options -S and -H? What hardware support is
needed for option -S? Is it a driver problem?

Thanks,
Jan

Re: [Linuxptp-users] Hardware timestamping does not work

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

On Sat, Nov 05, 2016 at 08:26:27PM +0100, Richard Cochran wrote:
>   testptp -g; sleep 60; testptp -g

But first reset the frequency offset, so do

    testptp -f 0; testptp -g; sleep 60; testptp -g

Thanks,
Richard

Re: [Linuxptp-users] Hardware timestamping does not work

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

On Sat, Nov 05, 2016 at 04:38:04PM +0100, Jan Deinhard wrote:
> I am using a Debian workstation and a i.MX6UL evaluation board running on a
> Linux build with Yocto. According to ethtool -T eth0 both systems support
> PTP hardware timestamping.

...

> ptp4l[26435.632]: master offset 4399753214 s2 freq +32767999 path delay
> -277121915
> 
> It is not getting better after some minutes. Master offset is alway
> increasing and freq is always the same value.

The frequency is locked here at maximum offset, and the device is not
converging.  This is most likely a driver or HW problem on the imx6.
 
> Workstation:
> 
> $ uname
> -a
> 
> Linux polaris 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
> x86_64 GNU/Linux
> 
> $ lspci
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
> I219-V (rev 31)

If this i219 is working with the igb driver, and the driver shows HW
time stamping enabled, then it should work well.  So this isn't the
problem, most likely.

> Eval board:
> 
> $ uname -a
> Linux imx6ulevk 4.1.15-2.0.0+gb63f3f5 #1 SMP PREEMPT Wed Nov 2 21:42:19 CET
> 2016 armv7l armv7l armv7l GNU/Linux

I have never tested the ptp driver for the imx6, and I am highly
suspicious of Freescale "quality" drivers.

> What can I do to find out what the problem is?

I guess that either the imx6 driver is broken by design, or that it is
mis-configured on your board.  I would verify that the input clock to
the time stamping unit is the same frequency as the driver expects, or
if the driver detects the frequency, that this is correct.

You will probably have to dig into the data sheet and into the driver
source.

Here is one simple sanity check for the clock.  Run

  testptp -g; sleep 60; testptp -g

and verify that the difference between the two outputs is about 60
seconds.

> Or am I misinterpreting the output?

Looks like a problem on the imx6.  You can run a test between the i219
and any other linux PC (even if that PC only has SW time stamping) in
order to exclude a problem with the i219.

> What does the "freq" value mean?

This is the adjustment in parts per billion.  Normally the magnitute
of this value should never exceed 100 ppm or so.

HTH,
Richard

[Linuxptp-users] Hardware timestamping does not work

[Jan D. <jan...@gm...>]

Hello,

I have problems setting up hardware timestamping with ptp4l version 1.6.
Probably it is a problem with my system but I am not sure how figure out
what is going wrong.

I am using a Debian workstation and a i.MX6UL evaluation board running on a
Linux build with Yocto. According to ethtool -T eth0 both systems support
PTP hardware timestamping.

With the workstation as master

$ ptp4l -i eth0 -m -H

and the eval board as slave

$ ptp4l -i eth0 -m -H -s

I see get the following output on the slave:

ptp4l[26422.241]: selected /dev/ptp0 as PTP clock
ptp4l[26422.248]: driver changed our HWTSTAMP options
ptp4l[26422.251]: tx_type   1 not 1
ptp4l[26422.253]: rx_filter 1 not 12
ptp4l[26422.255]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[26422.257]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[26423.632]: port 1: new foreign master d05099.fffe.82569e-1
ptp4l[26427.632]: selected best master clock d05099.fffe.82569e
ptp4l[26427.633]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[26428.632]: master offset 9027724697 s0 freq +32765433 path
delay         0
ptp4l[26429.632]: master offset 10110507943 s1 freq +32767999 path delay
-339142602
ptp4l[26431.632]: master offset 1443965638 s2 freq +32767999 path delay
-295834797
ptp4l[26431.634]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[26432.632]: master offset 2187585778 s2 freq +32767999 path delay
-295834797
ptp4l[26433.632]: master offset 2925385526 s2 freq +32767999 path delay
-290010958
ptp4l[26434.632]: master offset 3663195859 s2 freq +32767999 path delay
-284187119
ptp4l[26435.632]: master offset 4399753214 s2 freq +32767999 path delay
-277121915

It is not getting better after some minutes. Master offset is alway
increasing and freq is always the same value.

With the eval board as master and the workstation as slave I see the
following output on the slave:

ptp4l[28320.840]: selected /dev/ptp0 as PTP clock
ptp4l[28320.840]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[28320.841]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[28322.088]: port 1: new foreign master 00049f.fffe.03fc1c-1
ptp4l[28326.088]: selected best master clock 00049f.fffe.03fc1c
ptp4l[28326.088]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[28327.087]: master offset 125878074591 s0 freq -23999996 path
delay         0
ptp4l[28328.088]: master offset 125134345169 s1 freq -23999999 path
delay         0
ptp4l[28329.088]: master offset -737638119 s2 freq -23999999 path
delay         0
ptp4l[28329.088]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[28330.088]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[28330.088]: master offset -1475235977 s0 freq -23999999 path
delay         0
ptp4l[28330.088]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
ptp4l[28331.088]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[28331.088]: master offset -2419666334 s0 freq -23999999 path delay
206861774
ptp4l[28332.088]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[28332.088]: master offset -3089364053 s0 freq -23999999 path delay
138983131
ptp4l[28333.088]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[28333.089]: master offset -3866489723 s0 freq -23999999 path delay
178522823
ptp4l[28334.088]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[28334.089]: master offset -4617886979 s0 freq -23999999 path delay
192326258

It works somewhat better when I use software ts on the workstation and
hardware ts on the eval board but "freq" remains at a very high value on
the slave:

ptp4l[28788.508]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[28788.508]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[28794.533]: selected best master clock d05099.fffe.82569e
ptp4l[28799.399]: port 1: new foreign master 00049f.fffe.03fc1c-1
ptp4l[28801.119]: selected best master clock d05099.fffe.82569e
ptp4l[28803.399]: selected best master clock 00049f.fffe.03fc1c
ptp4l[28803.399]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[28805.399]: master offset 166527119067 s0 freq +25001504 path
delay     57163
(removed 15 lines)
ptp4l[28821.402]: master offset 166527038073 s1 freq +24996569 path
delay     61780
ptp4l[28823.402]: master offset      44731 s2 freq +25001087 path delay
61458
ptp4l[28823.402]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[28824.402]: master offset      14076 s2 freq +24998036 path delay
66101
ptp4l[28825.403]: master offset      -5574 s2 freq +24996065 path delay
66101
ptp4l[28826.403]: master offset      -3251 s2 freq +24996294 path delay
66101
ptp4l[28827.403]: master offset      -1000 s2 freq +24996518 path delay
66101
ptp4l[28828.403]: master offset       5890 s2 freq +24997213 path delay
60522
ptp4l[28829.403]: master offset      11802 s2 freq +24997816 path delay
55710
ptp4l[28830.403]: master offset      12450 s2 freq +24997893 path delay
55553
ptp4l[28831.404]: master offset      12918 s2 freq +24997953 path delay
55386
ptp4l[28832.404]: master offset      32581 s2 freq +24999952 path delay
55386

My current guess is a problem on my Linux system.

Here is more information on my setup:

Workstation:

$ uname
-a

Linux polaris 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
x86_64 GNU/Linux

$ lspci
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
I219-V (rev 31)

$ ethtool -T
eth0

Time stamping parameters for eth0:
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)
    ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
    ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
    ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
    ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
    ptpv2-l2-sync         (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
    ptpv2-l2-delay-req    (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
    ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
    ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
    ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)



Eval board:

$ uname -a
Linux imx6ulevk 4.1.15-2.0.0+gb63f3f5 #1 SMP PREEMPT Wed Nov 2 21:42:19 CET
2016 armv7l armv7l armv7l GNU/Linux

$ ethtool -T eth0
Time stamping parameters for eth0:
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)


What can I do to find out what the problem is?

Or am I misinterpreting the output?

What does the "freq" value mean?

Best regards
Jan

Re: [Linuxptp-users] pmc:: uds: sendto failed: No such file or directory

[David M. <dav...@gm...>]

Thanks Richard, for the concise and helpful reply!
I'll look into what switching to 1.7 would take as a preference (in
addition to making my stuff more robust anyway), but it's good to
understand what the underlying cause was.
Also for the notes on the master's dataset - I'll take a closer look at
what it's actually saying and go from there, worst case sounds like I can
ignore the logs.

Thanks again,
David M

On Fri, Nov 4, 2016 at 7:56 PM, Richard Cochran <ric...@gm...>
wrote:

> On Fri, Nov 04, 2016 at 08:25:04AM +1100, David Mirabito wrote:
> > Very occasionally I'm noticing that this fails, and I have a message in
> > syslog:
> >
> > user.err pmc: [94758.014] uds: sendto failed: No such file or directory
>
> This is a regression in v1.6 that was fixed in v1.7:
>
>    3938cbc uds: Prevent unintentional announce message timeouts.
>
> You can cherry pick that onto v1.6 or just switch to v1.7.
>
> > And it periodically logs (with gaps of 158, 28, 168, 56, 168 seconds
> > between the messages that I looked at) that:
> >
> > Oct 20 21:13:23 user.notice ptp4l: [94820.538] selected best master clock
> > 000cec.fffe.08046f
> >
> > Is this expected, the constant reminder that the same BMC is chosen time
> > after time, or would this be considered strange?
>
> This effect is normal, caused by any change in the master's data set.
> Honest GPS masters will update the grandmasterClockAccuracy field
> according to the current state of the GPS.
>
> Thanks,
> Richard
>

Re: [Linuxptp-users] pmc:: uds: sendto failed: No such file or directory

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

On Fri, Nov 04, 2016 at 08:25:04AM +1100, David Mirabito wrote:
> Very occasionally I'm noticing that this fails, and I have a message in
> syslog:
> 
> user.err pmc: [94758.014] uds: sendto failed: No such file or directory

This is a regression in v1.6 that was fixed in v1.7:

   3938cbc uds: Prevent unintentional announce message timeouts.

You can cherry pick that onto v1.6 or just switch to v1.7.

> And it periodically logs (with gaps of 158, 28, 168, 56, 168 seconds
> between the messages that I looked at) that:
> 
> Oct 20 21:13:23 user.notice ptp4l: [94820.538] selected best master clock
> 000cec.fffe.08046f
> 
> Is this expected, the constant reminder that the same BMC is chosen time
> after time, or would this be considered strange?

This effect is normal, caused by any change in the master's data set.
Honest GPS masters will update the grandmasterClockAccuracy field
according to the current state of the GPS.

Thanks,
Richard

[Linuxptp-users] pmc:: uds: sendto failed: No such file or directory

[David M. <dav...@gm...>]

Hi,

I have a long running process which needs to know about PTP state in order
to know if the PHC can be trusted, and in what ballpark. So I call out to
"pmc -u 'get DATASET' -d DOMAIN" and the output is easy enough to parse.
This works for the most part; so far so good.

Very occasionally I'm noticing that this fails, and I have a message in
syslog:

user.err pmc: [94758.014] uds: sendto failed: No such file or directory


As far as I can tell from the logs, ptp4l is still running before & after
this event so it's not that it has died or been stopped -- both phc2sys and
ptp4l are reliably logging their rms/max/freq/delay values every 64 seconds
as configures

Also, for what it's worth this device can see both a spectracom and an
arista master:

Oct 20 21:10:41 user.notice ptp4l: [94658.520] port 1: new foreign master
001c73.ffff.b53441-43
Oct 20 21:10:45 user.notice ptp4l: [94662.520] selected best master clock
000cec.fffe.08046f


And it periodically logs (with gaps of 158, 28, 168, 56, 168 seconds
between the messages that I looked at) that:

Oct 20 21:13:23 user.notice ptp4l: [94820.538] selected best master clock
000cec.fffe.08046f

Is this expected, the constant reminder that the same BMC is chosen time
after time, or would this be considered strange?

Now, I can (and should) make my wrapper be immune to the occasional uds
failure, but I'm wondering if this isn't symptomatic of something deeper?
Hacking a bandaid over it without understanding doesn't feel right..
Could there be some race condition on the uds, or other something else
(perhaps related to the BMC decision)?

Additional data points:
 * am running in slave-only mode and priority1=255, but otherwise standard.
 * running version is 1.6

And & all advice appreciated,
Thanks,
David