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

Re: [Linuxptp-users] Does not show the offset frequency etc..

[藍彥凱 <ggy...@gm...>]

Sorry,how should I make sure them?
If not,should I improve or modify which part?
Thank you for your help.

Richard Cochran <ric...@gm...>於 2021年12月13日 週一，10:20寫道：

>
> Please keep the mailing list on CC.  In that way, the community can
> benefit from the discussion.
>
> Thanks,
> Richard
>
>
> On Mon, Dec 13, 2021 at 09:58:51AM +0800, 藍彥凱 wrote:
> > Sorry,how should I make sure them?
> > If not,should I improve or modify which part?
> > Thank you for your help.
> >
> > 藍彥凱 <ggy...@gm...>於 2021年12月13日 週一，09:50寫道：
> >
> > > Sorry,how should I make sure them?
> > >
> > > Richard Cochran <ric...@gm...>於 2021年12月13日 週一，09:38寫道：
> > >
> > >> On Sun, Dec 12, 2021 at 06:21:10PM +0800, 藍彥凱 wrote:
> > >> > Hello, I tested ptp4l on two PC. The master clock display is
> correct,
> > >> > but from the clock display to port 1: LISTENING to UNCALIBRATED on
> > >> > RS_SLAVE, there is nothing to do. The master offset is not
> displayed.
> > >> > What is the problem?
> > >>
> > >> The client is not able to complete a delay measurement.  First, make
> > >> sure  delay requests and responses are getting through.
> > >>
> > >> Good luck,
> > >> Richard
> > >>
> > >
>

Re: [Linuxptp-users] Does not show the offset frequency etc..

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

On Sun, Dec 12, 2021 at 06:21:10PM +0800, 藍彥凱 wrote:
> Hello, I tested ptp4l on two PC. The master clock display is correct,
> but from the clock display to port 1: LISTENING to UNCALIBRATED on
> RS_SLAVE, there is nothing to do. The master offset is not displayed.
> What is the problem?

The client is not able to complete a delay measurement.  First, make
sure  delay requests and responses are getting through.

Good luck,
Richard

[Linuxptp-users] Does not show the offset frequency etc..

[藍彥凱 <ggy...@gm...>]

Hello, I tested ptp4l on two PC. The master clock display is correct,
but from the clock display to port 1: LISTENING to UNCALIBRATED on
RS_SLAVE, there is nothing to do. The master offset is not displayed.
What is the problem?

chu@chu-ThinkStation-S30:~$ sudo ptp4l -i eno1 -s -m -S

ptp4l[2711616.630]: port 1 (eno1): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[2711616.630]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING
on INIT_COMPLETE
ptp4l[2711616.630]: port 0 (/var/run/ptp4lro): INITIALIZING to
LISTENING on INIT_COMPLETE
ptp4l[2711618.664]: port 1 (eno1): new foreign master d45d64.fffe.3ffc8b-1
ptp4l[2711622.664]: selected best master clock d45d64.fffe.3ffc8b
ptp4l[2711622.664]: foreign master not using PTP timescale
ptp4l[2711622.664]: port 1 (eno1): LISTENING to UNCALIBRATED on RS_SLAVE

Thanks

Re: [Linuxptp-users] Redundant boundary clocks

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

On Fri, Dec 10, 2021 at 11:29:25AM +0100, Marco Davids (SIDN) via Linuxptp-users wrote:
> Hi there,
> 
> Here's a newcomers question.
> 
> I am working out a setup with two master clocks (one GM/leader, one
> slave/follower, depending on what BMCA decides) and two boundary clocks that
> both slave from the above setup and both provide time to the same vlan on
> the other side. The BC's are slave only toward the GM and master only toward
> the clients on the other side:

Don't configure "slave only" on the BC.  They will naturally form a
spanning tree without that.

Then your OC will have only one choice.

HTH,
Richard

Re: [Linuxptp-users] Linuxptp for Masterclock simulation

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

On Fri, Dec 10, 2021 at 12:51:10PM +0000, Kirchhoff, Philip wrote:
> Ok, but do I need to configure anything explicitly for this? How does the Lib know that it should act as GM.

You can run the DUT with --clientOnly (aka -s)

Or you can bump the --priority1 or --priority2 on the GM.

Thanks,
Richard

Re: [Linuxptp-users] Redundant boundary clocks

[Marco D. (SIDN) <mar...@si...>]

Hi Dennis,

Op 10-12-21 om 13:21 schreef Dennis Hagarty (dehagart):

> the profile can have a large influence on this.

> What PTP profiles are you using and what transport (L2 or L3?)
> What are the two BC's sending out in their announce message?
> 
> How is the OC connected to VLAN2? Is it using another switch?


Let me try to answer your questions at the risk of saying silly being 
the rookie that I am.

At the moment I'm testing my setup in an VM-environment with 5 guests on 
a host, to see if it is a viable concept. In the ultimate situation it 
will consist of physical servers, switches and hardware timestamping, 
geographically separated. The OC might be on another switch.

The reason for creating VLAN 2 is because I wouldn't want to allow 
(untrusted) clients in VLAN1.

Both BC's send the grandmasterClockIdentity and other fields (like 
TimeSource) of the true, current GM in VLAN1, as well as their own 
unique ClockIdentity. And they adapt well, if BMCA causes a flip. So 
they seem to pass all that information on quite well, like a BC should, 
I assume.

I believe I'm using a custom PTP profile, because I took the default 
configuration of ptp4l and fiddled around a bit with a couple of settings.

My transport is L3-E2E multicast (tried unicast too, but that was not an 
improvement per se).

In VLAN1 everything works well. There's a GM and a backup-clock. And the 
two BC's behave as slaves/followers.

In VLAN2 I have my doubts. Both BC's seem to be in a master role and the 
OC appears to use them both more or less alternating, whereas I would 
prefer/expect one of the BC's to be silent and only become active when 
needed.

So, I guess my primary question (for now) is: if this approach is at all 
good practice; is it possible to have two BC's in one VLAN?

I found a picture on 
https://en.wikipedia.org/wiki/Precision_Time_Protocol_Industry_Profile 
that resembles what I have in mind, with one exception:

https://en.wikipedia.org/wiki/File:IEEE_1588_Network_Elements_170208_HK.jpg

In my plan, there are no subdomain B an C. Just one cloud, with two 
available BC's for redundancy.

Thanks for your help!

-- 
Marco

Re: [Linuxptp-users] question about uds_address in phc2sys, ptp4l

[Ed B. <br...@ar...>]

With the -w argument, phc2sys uses this port to communicate with ptp4l 
to wait until ptp4l is tracking and to get the UTC offset propagated 
from PTP protocol.

- ed

On 12/10/21 02:44, Kat Y wrote:
> Hi,
> 
> I am running two instances of ptp4l on separate interfaces, one is 
> master and one is slave.
> I have changed their uds_address to be different per iface 
> (/var/run/ptp4leth0 and /var/run/ptp4leth1).
> That is the uds_address that I give to 'pmc' and I get the correct response.
> 
> I was wondering, is uds_address only used for communication with 'pmc'?
> If I have 'phc2sys' instance tied to eth0 interface, it's uds_address 
> can be random? Does phc2sys communicate with anyone or is it there just 
> in case I want to grab it's status with 'pmc'?
> 
> Thank you!
> Katarina
> 
> 
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
> 

Re: [Linuxptp-users] Linuxptp for Masterclock simulation

[Kirchhoff, P. <phi...@si...>]

Ok, but do I need to configure anything explicitly for this? How does the Lib know that it should act as GM.
________________________________
From: Richard Cochran <ric...@gm...>
Sent: Thursday, December 9, 2021 10:19 PM
To: Kirchhoff, Philip (SE GP T HG PE T 1 2) <phi...@si...>
Cc: lin...@li... <lin...@li...>
Subject: Re: [Linuxptp-users] Linuxptp for Masterclock simulation

On Thu, Dec 09, 2021 at 09:08:12AM +0000, Kirchhoff, Philip wrote:
> I may have expressed myself in a misleading way. I do not want to simulate a clock network.
> I have an embedded device that should synchronize its time via PTP. Since I don't have a HW clock available, I want my PC (or maybe an RPI) to act as master clock and connect it to the device. The time source for the master clock should be the system time of my PC.

Yes, that works just fine.  At the end of the day, there is nothing
special about a GM.  It need not be hooked to GPS or DCF77 or anything
at all.

HTH,
Richard

[Linuxptp-users] Redundant boundary clocks

[Marco D. (SIDN) <mar...@si...>]

Hi there,

Here's a newcomers question.

I am working out a setup with two master clocks (one GM/leader, one 
slave/follower, depending on what BMCA decides) and two boundary clocks 
that both slave from the above setup and both provide time to the same 
vlan on the other side. The BC's are slave only toward the GM and master 
only toward the clients on the other side:

GM     slave
  |       |
-----------   <-- VLAN 1
  |       |
BC      BC
  |       |
-----------   <-- VLAN 2
      |
      OC

(BC's are LinuxPTP)

What I'm trying to achieve is a redundant BC-situation for the OC, with 
the goal of making things more resilient.

It looks like the OC can't seem to decide between BC's to use for 
synchronisation. It appears to use both every now and then. I use 
multicast (tried unicast to, but that seems to make things worse, 
sometimes causing the OC to stop syncing all together).

My question: is a setup with redudant BC's at all possible? Or isn't 
this recommended?

Any advice?

Thanks!

-- 
Marco

[Linuxptp-users] question about uds_address in phc2sys, ptp4l

[Kat Y <aps...@gm...>]

Hi,

I am running two instances of ptp4l on separate interfaces, one is master
and one is slave.
I have changed their uds_address to be different per iface
(/var/run/ptp4leth0 and /var/run/ptp4leth1).
That is the uds_address that I give to 'pmc' and I get the correct response.

I was wondering, is uds_address only used for communication with 'pmc'?
If I have 'phc2sys' instance tied to eth0 interface, it's uds_address can
be random? Does phc2sys communicate with anyone or is it there just in case
I want to grab it's status with 'pmc'?

Thank you!
Katarina

Re: [Linuxptp-users] Linuxptp for Masterclock simulation

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

On Thu, Dec 09, 2021 at 09:08:12AM +0000, Kirchhoff, Philip wrote:
> I may have expressed myself in a misleading way. I do not want to simulate a clock network.
> I have an embedded device that should synchronize its time via PTP. Since I don't have a HW clock available, I want my PC (or maybe an RPI) to act as master clock and connect it to the device. The time source for the master clock should be the system time of my PC.

Yes, that works just fine.  At the end of the day, there is nothing
special about a GM.  It need not be hooked to GPS or DCF77 or anything
at all.

HTH,
Richard

Re: [Linuxptp-users] Linuxptp for Masterclock simulation

[Kirchhoff, P. <phi...@si...>]

I may have expressed myself in a misleading way. I do not want to simulate a clock network.
I have an embedded device that should synchronize its time via PTP. Since I don't have a HW clock available, I want my PC (or maybe an RPI) to act as master clock and connect it to the device. The time source for the master clock should be the system time of my PC.
________________________________
From: Richard Cochran <ric...@gm...>
Sent: Wednesday, December 8, 2021 4:06 PM
To: Kirchhoff, Philip (SE GP T HG PE T 1 2) <phi...@si...>
Cc: lin...@li... <lin...@li...>
Subject: Re: [Linuxptp-users] Linuxptp for Masterclock simulation

On Wed, Dec 08, 2021 at 07:32:10AM +0000, Kirchhoff, Philip wrote:
> Hi,
>
> I was wondering if it is possible with linuxptp to simulate a PTP masterclock on a PC. I realize that I can't achieve reasonable accuracy with it. It is only about the simulation of the protocol.

Sure, you can run ptp4l over tun/tap interfaces, for example.

Or maybe you can use Miroslav's awesome simulation environment:

   https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlichvar%2Flinuxptp-testsuite&amp;data=04%7C01%7Cphilip.kirchhoff%40siemens-energy.com%7C4a6d1b835a524103fa1708d9ba5c427b%7C254ba93e1f6f48f390e6e2766664b477%7C1%7C0%7C637745727674174875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2cXVR8s5snY7RZjFg3m3ZNEAGptDsr55B8J0%2BlrbbOU%3D&amp;reserved=0
   https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlichvar%2Fclknetsim&amp;data=04%7C01%7Cphilip.kirchhoff%40siemens-energy.com%7C4a6d1b835a524103fa1708d9ba5c427b%7C254ba93e1f6f48f390e6e2766664b477%7C1%7C0%7C637745727674174875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=nqwqfAhen%2Bo9eFjOEdqc3qXOW18fn1bnoyIjxs37oNU%3D&amp;reserved=0

HTH,
Richard

Re: [Linuxptp-users] ptp4l shows very large offset and tries to correct it, but the offset isn't realy there

[Maximilian K. <max...@tu...>]

Am 2021-12-08 10:42, schrieb Maximilian Kirchner:

> Am 2021-12-07 17:31, schrieb Richard Cochran:
> On Tue, Dec 07, 2021 at 11:27:19AM +0100, Maximilian Kirchner wrote: 
> Hello,
> 
> I hope someone may be able to help me here. I have trouble syncing two 
> Linux
> systems using PTP.
> 
> Setup:
> 
> Two PCBs with a BegleCore module and a DP83640 PHY are connected with 
> each
> other over Ethernet. One board should act as the PTP master, the other 
> as
> the slave.
> You want to use the PTP features in the phyters.
> 
> First step is to make sure the MAC driver isn't also doing time
> stamping.
> 
> I assume your MAC has the CPTS and will muck things up.  I have had to
> hack the CPTS support away in some cases.
> 
> Thanks,
> Richard

Hi,

the SoC used on the BeagleCore modules does indead have a CPTS module.

To see if it helps, I recompiled and replaced the kernel, now with the 
option for "TI Common PLatofrm Time Sync (CPTS) Support" turned off.

This now resulted in ptp4l to not running at all. The output is now the 
following:

ptp4l[1614.335]: selected /dev/ptp0 as PTP clock
ptp4l[1614.348]: driver rejected most general HWTSTAMP filter
ptp4l[1614.351]: ioctl SIOCSHWTSTAMP failed: Operation not supported
ptp4l[1614.355]: port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED 
(FT_UNSPECIFIED)
ptp4l[1614.359]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on 
INIT_COMPLETE
ptp4l[1614.363]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on 
INIT_COMPLETE

It doesn't go further.

The command "./hwstamp_ctl -i eth0" returned:

Device driver does not have support for non-destructive SIOCGHWTSTAMP.

Now I dont know if I made it worse, or if this is the first step to a 
solution :-/
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Hello,

I would like to let you know that I was able to fix my problem.

Thank you very much for your tip regarding the CPTS.

After disabling the CPTS in the kernel, I also had to change the 
following:

diff --git a/drivers/net/ethernet/ti/cpsw.c 
b/drivers/net/ethernet/ti/cpsw.c
index fc8e3ed383a2..d4d70706e86c 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2490,15 +2490,22 @@ static int cpsw_ndo_ioctl(struct net_device 
*dev, struct ifreq *req, int cmd)
struct cpsw_priv *priv = netdev_priv(dev);
struct cpsw_common *cpsw = priv->cpsw;
int slave_no = cpsw_slave_index(cpsw, priv);
+ int err = 0;

if (!netif_running(dev))
return -EINVAL;

switch (cmd) {
case SIOCSHWTSTAMP:
- return cpsw_hwtstamp_set(dev, req);
+ err = cpsw_hwtstamp_set(dev, req);
+ if(err != -EOPNOTSUPP)
+ return err;
+ break;
case SIOCGHWTSTAMP:
- return cpsw_hwtstamp_get(dev, req);
+ err = cpsw_hwtstamp_get(dev, req);
+ if(err != -EOPNOTSUPP)
+ return err;
+ break;
case SIOCSWITCHCONFIG:
return cpsw_switch_config_ioctl(dev, req, cmd);
}

Not sure if it is the most elegant thing to do, but it works now.

Best regards

Maximilian Kirchner

Re: [Linuxptp-users] Linuxptp for Masterclock simulation

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

On Wed, Dec 08, 2021 at 07:32:10AM +0000, Kirchhoff, Philip wrote:
> Hi,
> 
> I was wondering if it is possible with linuxptp to simulate a PTP masterclock on a PC. I realize that I can't achieve reasonable accuracy with it. It is only about the simulation of the protocol.

Sure, you can run ptp4l over tun/tap interfaces, for example.

Or maybe you can use Miroslav's awesome simulation environment:

   https://github.com/mlichvar/linuxptp-testsuite
   https://github.com/mlichvar/clknetsim

HTH,
Richard

Re: [Linuxptp-users] ptp4l shows very large offset and tries to correct it, but the offset isn't realy there

[Maximilian K. <max...@tu...>]

Am 2021-12-07 17:31, schrieb Richard Cochran:

> On Tue, Dec 07, 2021 at 11:27:19AM +0100, Maximilian Kirchner wrote:
> 
>> Hello,
>> 
>> I hope someone may be able to help me here. I have trouble syncing two 
>> Linux
>> systems using PTP.
>> 
>> Setup:
>> 
>> Two PCBs with a BegleCore module and a DP83640 PHY are connected with 
>> each
>> other over Ethernet. One board should act as the PTP master, the other 
>> as
>> the slave.
> 
> You want to use the PTP features in the phyters.
> 
> First step is to make sure the MAC driver isn't also doing time
> stamping.
> 
> I assume your MAC has the CPTS and will muck things up.  I have had to
> hack the CPTS support away in some cases.
> 
> Thanks,
> Richard

Hi,

the SoC used on the BeagleCore modules does indead have a CPTS module.

To see if it helps, I recompiled and replaced the kernel, now with the 
option for "TI Common PLatofrm Time Sync (CPTS) Support" turned off.

This now resulted in ptp4l to not running at all. The output is now the 
following:

ptp4l[1614.335]: selected /dev/ptp0 as PTP clock
ptp4l[1614.348]: driver rejected most general HWTSTAMP filter
ptp4l[1614.351]: ioctl SIOCSHWTSTAMP failed: Operation not supported
ptp4l[1614.355]: port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED 
(FT_UNSPECIFIED)
ptp4l[1614.359]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on 
INIT_COMPLETE
ptp4l[1614.363]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on 
INIT_COMPLETE

It doesn't go further.

The command "./hwstamp_ctl -i eth0" returned:

Device driver does not have support for non-destructive SIOCGHWTSTAMP.

Now I dont know if I made it worse, or if this is the first step to a 
solution :-/

Re: [Linuxptp-users] Linuxptp for Masterclock simulation

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

On Wed, Dec 08, 2021 at 07:32:10AM +0000, Kirchhoff, Philip wrote:
> Hi,
> 
> I was wondering if it is possible with linuxptp to simulate a PTP masterclock on a PC. I realize that I can't achieve reasonable accuracy with it. It is only about the simulation of the protocol.

There is a testsuite using simulations:
https://github.com/mlichvar/linuxptp-testsuite

Depending on what exactly you need to test, you could just modify one
of the existing scripts.

-- 
Miroslav Lichvar

[Linuxptp-users] Linuxptp for Masterclock simulation

[Kirchhoff, P. <phi...@si...>]

Hi,

I was wondering if it is possible with linuxptp to simulate a PTP masterclock on a PC. I realize that I can't achieve reasonable accuracy with it. It is only about the simulation of the protocol.


Regards

Philip

Re: [Linuxptp-users] Intermittent send delay request failure (tx_timestamp_timeout) w/dp83640

[Dan G. <gee...@gm...>]

This is a huge help!  Thank you very much!

I set the Tx timestamp up to 50 ms to ensure that it wasn't creating
confusion.  So far I've found that the PSF_TX status frames (TX Timestamps)
are not coming back to the dp83640 driver when the problem shows up.  I
think I'm on the right track.  And, I should be able to squash the bug from
here.

Thanks again!
-Dan

On Tue, Dec 7, 2021 at 11:27 AM Richard Cochran <ric...@gm...>
wrote:

> On Tue, Dec 07, 2021 at 06:30:32AM -0500, Dan Geer wrote:
> > So, I'm into the phyter device driver...  What's the next step?
>
> The phyter generates special frames that carry the time stamps.  These
> frames are delivered to the host.  Because the frames appear to be PTP
> frames, the networking stack will deliver them to the phy driver via
>
> skb_defer_rx_timestamp()
>
> So the flow is:
>
> 1. host sends a PTP event message
> 2. phyter time stamps it and generates a frame back to the host
> 3. frame is delivered to the phy driver via mii_ts->rxtstamp()
> 4. driver decodes frame and delivers cmsg to user space
>
> The default Tx timestamp timeout is 1 ms.  Maybe your NW stack is just
> a bit too slow.  Try increasing the timeout to 10 ms.
>
> Another thing to consider about the phyter:  It generates these
> special frames, but only when there is some bandwidth left to send
> them.  It will not preempt normal NW traffic.  That means you cannot
> use the 100 Mbit completely.
>
> HTH,
> Richard
>
>

Re: [Linuxptp-users] ptp4l shows very large offset and tries to correct it, but the offset isn't realy there

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

On Tue, Dec 07, 2021 at 11:27:19AM +0100, Maximilian Kirchner wrote:
> Hello,
> 
> I hope someone may be able to help me here. I have trouble syncing two Linux
> systems using PTP.
> 
> Setup:
> 
> Two PCBs with a BegleCore module and a DP83640 PHY are connected with each
> other over Ethernet. One board should act as the PTP master, the other as
> the slave.

You want to use the PTP features in the phyters.

First step is to make sure the MAC driver isn't also doing time
stamping.

I assume your MAC has the CPTS and will muck things up.  I have had to
hack the CPTS support away in some cases.

Thanks,
Richard

Re: [Linuxptp-users] Intermittent send delay request failure (tx_timestamp_timeout) w/dp83640

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

On Tue, Dec 07, 2021 at 06:30:32AM -0500, Dan Geer wrote:
> So, I'm into the phyter device driver...  What's the next step?

The phyter generates special frames that carry the time stamps.  These
frames are delivered to the host.  Because the frames appear to be PTP
frames, the networking stack will deliver them to the phy driver via

skb_defer_rx_timestamp()

So the flow is:

1. host sends a PTP event message
2. phyter time stamps it and generates a frame back to the host
3. frame is delivered to the phy driver via mii_ts->rxtstamp()
4. driver decodes frame and delivers cmsg to user space

The default Tx timestamp timeout is 1 ms.  Maybe your NW stack is just
a bit too slow.  Try increasing the timeout to 10 ms.

Another thing to consider about the phyter:  It generates these
special frames, but only when there is some bandwidth left to send
them.  It will not preempt normal NW traffic.  That means you cannot
use the 100 Mbit completely.

HTH,
Richard

Re: [Linuxptp-users] Intermittent send delay request failure (tx_timestamp_timeout) w/dp83640

[Dan G. <gee...@gm...>]

On Dec 6, 2021, at 8:34 PM, Richard Cochran <ric...@gm...>
wrote:

On Mon, Dec 06, 2021 at 07:27:54AM -0500, Dan Geer wrote:

I would like to start with my thanks for the support of the Linux PTP

Project.  The tools are a great success, and keep getting better!


I'm developing a custom SBC that works perfectly approximately 90% of the

time.  However, when the SBC starts or restarts there are cases immediately

after initialization where ptp4l goes into a repeating cycle of 1) syncing

to a PTP Grand Master, 2) timing out on the port_delay_request, and 3)

resetting the failed port.


My SBC is based on a MPC8360E (NXP PowerQUICC® II Pro Processor with

ucc_geth MACs) connected to DP83640 PHYTERs.


You want to use the PTP features in the phyters.

First step is to make sure the MAC driver isn't also doing time
stamping.

I don't see PTP support in mainline ucc_geth, but maybe you have a
vendor kernel with time stamping patched in?

Thanks,
Richard

Richard,
Thanks for the quick response!
No vendor kernel involved. I have the mainline ucc_geth.  On the transmit
side, the ucc_geth_start_xmit function calls skb_tx_timestamp(skb) which
hooks into the mii_ts->txtstamp() function pointing to dp83640.c
The phyter is doing the timestamp via the PHY MII timestamp interface.
I've been going through the driver code, and all of the components seem to
be in there.  I'm using Documentation/networking/timestamping.rst as my
reference.
So, I'm into the phyter device driver...  What's the next step?
Thanks again,
Dan

[Linuxptp-users] ptp4l shows very large offset and tries to correct it, but the offset isn't realy there

[Maximilian K. <max...@tu...>]

Hello,

I hope someone may be able to help me here. I have trouble syncing two 
Linux systems using PTP.

Setup:

Two PCBs with a BegleCore module and a DP83640 PHY are connected with 
each other over Ethernet. One board should act as the PTP master, the 
other as the slave.
Debian 10, Kernel: 4.19.94
Driver for the Phy is loaded.
Using linuxptp v3.1

On the master system I run the command:

     sudo ptp4l -i eth0 -f linuxptp/configs/configMaster.cfg -m

On the client system I run:

     sudo ptp4l -i eth0 -f linuxptp/configs/configslave.cfg -m

Content of configMaster.cfg:

     [global]
     serverOnly 1
     BMCA noop

Content of configSlave.cfg:

     [global]
     clientOnly 1
     BMCA noop
     step_threshold 1

This results in the following output on the slave:

ptp4l[438753.396]: selected /dev/ptp0 as PTP clock
ptp4l[438753.409]: port 1 (eth0): INITIALIZING to SLAVE on INIT_COMPLETE
ptp4l[438753.414]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on 
INIT_COMPLETE
ptp4l[438753.418]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING 
on INIT_COMPLETE
ptp4l[438754.075]: port 1 (eth0): new foreign master 
304511.fffe.0ff048-1
ptp4l[438758.074]: selected best master clock 304511.fffe.0ff048
ptp4l[438762.072]: master offset 2426120726467 s0 freq -261066 path 
delay 15040
ptp4l[438762.074]: selected best master clock 304511.fffe.0ff048
ptp4l[438765.074]: master offset 2426120697575 s1 freq -270698 path 
delay 15156
ptp4l[438767.072]: master offset 2426120678191 s0 freq -270698 path 
delay 15156
ptp4l[438768.075]: master offset 2426120668273 s1 freq -280618 path 
delay 15830
ptp4l[438769.072]: master offset 2426120658469 s0 freq -280618 path 
delay 15830
ptp4l[438770.073]: master offset 2426120648789 s0 freq -280618 path 
delay 16022
ptp4l[438771.076]: master offset 2426120639057 s1 freq -290350 path 
delay 16022
...

The reported offset is approximatly 40 min. Before running ptp4l I had 
set the PTP clocks in the PHYs with `testptp -s` to the current system 
time. The PTP clocks were therefore actually within a few seconds of 
each other.

Each time ptp4l reports a "master offset <x> s1 ..." it does step the 
PTP clock back by 40 min (checked with `testptp -g`). Yet the reported 
offset only changes by about 10 us.

I also looked into the network traffic with Wireshark and saw, that the 
Follow-Up messages from the master contain a timestamp that is by about 
69 min of what the PTP clock in the PHY is set to.

After adding debug outputs to ptp4l I saw, that on the slave, the 
timestamp it extracts from the cmsgs returned from the socket is offset 
by about -27 min from what the client PTP clock actually is.

In detail: In sk.c after line 377 (ts = (struct timespec *) 
CMSG_DATA(cm);) I printed out the value of ts[2].tv_sec, wich, as far as 
I can tell, will sometime later be used to calculate the master offset.

This resulted in an ouput of for example: 1638869732 s.

When I read the value of the PTP clock the same way the tool testptp 
does, by opening the /dev/ptp0 device and calling clock_gettime(...), I 
would get 1638867306 s

The difference from the false timestamps (+69 min) send by the master 
and the falsely read timestamps (-27 min) by the client results in the 
40 min of assumed offset between the master clock and the client clock.

Here the output with -l 7 added for debug info:

bcm@BCM-4:~$ sudo ptp4l -i eth0 -f linuxptp/configs/configSlave.cfg -m 
-l 7
ptp4l[526775.711]: config item (null).assume_two_step is 0
ptp4l[526775.718]: config item (null).check_fup_sync is 0
ptp4l[526775.720]: config item (null).tx_timestamp_timeout is 10
ptp4l[526775.723]: config item (null).hwts_filter is 0
ptp4l[526775.725]: config item (null).clock_servo is 0
ptp4l[526775.727]: config item (null).clock_type is 32768
ptp4l[526775.728]: config item (null).clock_servo is 0
ptp4l[526775.729]: config item (null).clockClass is 248
ptp4l[526775.733]: config item (null).clockAccuracy is 254
ptp4l[526775.733]: config item (null).offsetScaledLogVariance is 65535
ptp4l[526775.734]: config item (null).productDescription is ';;'
ptp4l[526775.734]: config item (null).revisionData is ';;'
ptp4l[526775.736]: config item (null).userDescription is ''
ptp4l[526775.737]: config item (null).manufacturerIdentity is '00:00:00'
ptp4l[526775.739]: config item (null).domainNumber is 0
ptp4l[526775.739]: config item (null).clientOnly is 1
ptp4l[526775.740]: config item (null).gmCapable is 1
ptp4l[526775.741]: config item (null).gmCapable is 1
ptp4l[526775.743]: config item (null).G.8275.defaultDS.localPriority is 
128
ptp4l[526775.744]: config item (null).maxStepsRemoved is 255
ptp4l[526775.745]: config item (null).clock_class_threshold is 248
ptp4l[526775.745]: config item (null).time_stamping is 1
ptp4l[526775.745]: config item (null).twoStepFlag is 1
ptp4l[526775.748]: config item (null).twoStepFlag is 1
ptp4l[526775.749]: config item (null).time_stamping is 1
ptp4l[526775.749]: config item (null).priority1 is 128
ptp4l[526775.750]: config item (null).priority2 is 128
ptp4l[526775.751]: interface index 4 is up
ptp4l[526775.757]: config item (null).free_running is 0
ptp4l[526775.758]: selected /dev/ptp0 as PTP clock
ptp4l[526775.759]: config item (null).clockIdentity is 
'000000.0000.000000'
ptp4l[526775.761]: config item (null).uds_address is '/var/run/ptp4l'
ptp4l[526775.763]: section item /var/run/ptp4l.announceReceiptTimeout 
now 0
ptp4l[526775.767]: section item /var/run/ptp4l.delay_mechanism now 0
ptp4l[526775.767]: section item /var/run/ptp4l.network_transport now 0
ptp4l[526775.768]: section item /var/run/ptp4l.delay_filter_length now 1
ptp4l[526775.769]: config item (null).uds_ro_address is 
'/var/run/ptp4lro'
ptp4l[526775.771]: section item /var/run/ptp4lro.announceReceiptTimeout 
now 0
ptp4l[526775.772]: section item /var/run/ptp4lro.delay_mechanism now 0
ptp4l[526775.772]: section item /var/run/ptp4lro.network_transport now 0
ptp4l[526775.773]: section item /var/run/ptp4lro.delay_filter_length now 
1
ptp4l[526775.774]: config item (null).free_running is 0
ptp4l[526775.777]: config item (null).freq_est_interval is 1
ptp4l[526775.777]: config item (null).write_phase_mode is 0
ptp4l[526775.777]: config item (null).gmCapable is 1
ptp4l[526775.778]: config item (null).kernel_leap is 1
ptp4l[526775.778]: config item (null).utc_offset is 37
ptp4l[526775.780]: config item (null).timeSource is 160
ptp4l[526775.781]: config item (null).step_window is 0
ptp4l[526775.785]: config item (null).pi_proportional_const is 0.000000
ptp4l[526775.786]: config item (null).pi_integral_const is 0.000000
ptp4l[526775.787]: config item (null).pi_proportional_scale is 0.000000
ptp4l[526775.787]: config item (null).pi_proportional_exponent is 
-0.300000
ptp4l[526775.787]: config item (null).pi_proportional_norm_max is 
0.700000
ptp4l[526775.788]: config item (null).pi_integral_scale is 0.000000
ptp4l[526775.789]: config item (null).pi_integral_exponent is 0.400000
ptp4l[526775.789]: config item (null).pi_integral_norm_max is 0.300000
ptp4l[526775.789]: config item (null).step_threshold is 1.000000
ptp4l[526775.790]: config item (null).first_step_threshold is 0.000020
ptp4l[526775.790]: config item (null).max_frequency is 900000000
ptp4l[526775.792]: config item (null).servo_offset_threshold is 0
ptp4l[526775.793]: config item (null).servo_num_offset_values is 10
ptp4l[526775.794]: config item (null).dataset_comparison is 0
ptp4l[526775.797]: config item (null).tsproc_mode is 0
ptp4l[526775.797]: config item (null).delay_filter is 1
ptp4l[526775.798]: config item (null).delay_filter_length is 10
ptp4l[526775.798]: config item (null).initial_delay is 0
ptp4l[526775.801]: config item (null).summary_interval is 0
ptp4l[526775.801]: config item (null).sanity_freq_limit is 200000000
ptp4l[526775.801]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[526775.803]: config item /var/run/ptp4l.boundary_clock_jbod is 0
ptp4l[526775.804]: config item /var/run/ptp4l.serverOnly is 0
ptp4l[526775.806]: config item /var/run/ptp4l.BMCA is 1
ptp4l[526775.807]: config item /var/run/ptp4l.network_transport is 0
ptp4l[526775.807]: config item /var/run/ptp4l.delayAsymmetry is 0
ptp4l[526775.808]: config item /var/run/ptp4l.follow_up_info is 0
ptp4l[526775.811]: config item /var/run/ptp4l.freq_est_interval is 1
ptp4l[526775.811]: config item /var/run/ptp4l.msg_interval_request is 0
ptp4l[526775.812]: config item /var/run/ptp4l.net_sync_monitor is 0
ptp4l[526775.813]: config item /var/run/ptp4l.path_trace_enabled is 0
ptp4l[526775.815]: config item /var/run/ptp4l.tc_spanning_tree is 0
ptp4l[526775.816]: config item /var/run/ptp4l.ingressLatency is 0
ptp4l[526775.816]: config item /var/run/ptp4l.egressLatency is 0
ptp4l[526775.817]: config item /var/run/ptp4l.delay_mechanism is 0
ptp4l[526775.817]: config item /var/run/ptp4l.hybrid_e2e is 0
ptp4l[526775.820]: config item /var/run/ptp4l.fault_badpeernet_interval 
is 16
ptp4l[526775.821]: config item /var/run/ptp4l.fault_reset_interval is 4
ptp4l[526775.822]: config item /var/run/ptp4l.tsproc_mode is 0
ptp4l[526775.822]: config item /var/run/ptp4l.delay_filter is 1
ptp4l[526775.822]: config item /var/run/ptp4l.delay_filter_length is 1
ptp4l[526775.824]: config item /var/run/ptp4lro.boundary_clock_jbod is 0
ptp4l[526775.825]: config item /var/run/ptp4lro.serverOnly is 0
ptp4l[526775.825]: config item /var/run/ptp4lro.BMCA is 1
ptp4l[526775.826]: config item /var/run/ptp4lro.network_transport is 0
ptp4l[526775.827]: config item /var/run/ptp4lro.delayAsymmetry is 0
ptp4l[526775.828]: config item /var/run/ptp4lro.follow_up_info is 0
ptp4l[526775.831]: config item /var/run/ptp4lro.freq_est_interval is 1
ptp4l[526775.832]: config item /var/run/ptp4lro.msg_interval_request is 
0
ptp4l[526775.832]: config item /var/run/ptp4lro.net_sync_monitor is 0
ptp4l[526775.835]: config item /var/run/ptp4lro.path_trace_enabled is 0
ptp4l[526775.835]: config item /var/run/ptp4lro.tc_spanning_tree is 0
ptp4l[526775.835]: config item /var/run/ptp4lro.ingressLatency is 0
ptp4l[526775.836]: config item /var/run/ptp4lro.egressLatency is 0
ptp4l[526775.837]: config item /var/run/ptp4lro.delay_mechanism is 0
ptp4l[526775.839]: config item /var/run/ptp4lro.hybrid_e2e is 0
ptp4l[526775.840]: config item 
/var/run/ptp4lro.fault_badpeernet_interval is 16
ptp4l[526775.841]: config item /var/run/ptp4lro.fault_reset_interval is 
4
ptp4l[526775.841]: config item /var/run/ptp4lro.tsproc_mode is 0
ptp4l[526775.841]: config item /var/run/ptp4lro.delay_filter is 1
ptp4l[526775.842]: config item /var/run/ptp4lro.delay_filter_length is 1
ptp4l[526775.844]: config item (null).slave_event_monitor is ''
ptp4l[526775.845]: config item eth0.boundary_clock_jbod is 0
ptp4l[526775.845]: config item eth0.serverOnly is 0
ptp4l[526775.846]: config item eth0.BMCA is 1
ptp4l[526775.846]: config item eth0.network_transport is 1
ptp4l[526775.848]: config item eth0.delayAsymmetry is 0
ptp4l[526775.849]: config item eth0.follow_up_info is 0
ptp4l[526775.849]: config item eth0.freq_est_interval is 1
ptp4l[526775.850]: config item eth0.msg_interval_request is 0
ptp4l[526775.850]: config item eth0.net_sync_monitor is 0
ptp4l[526775.852]: config item eth0.path_trace_enabled is 0
ptp4l[526775.854]: config item eth0.tc_spanning_tree is 0
ptp4l[526775.855]: config item eth0.ingressLatency is 0
ptp4l[526775.855]: config item eth0.egressLatency is 0
ptp4l[526775.856]: config item eth0.delay_mechanism is 1
ptp4l[526775.856]: config item eth0.unicast_master_table is 0
ptp4l[526775.859]: config item eth0.unicast_listen is 0
ptp4l[526775.859]: config item eth0.hybrid_e2e is 0
ptp4l[526775.860]: config item eth0.fault_badpeernet_interval is 16
ptp4l[526775.860]: config item eth0.fault_reset_interval is 4
ptp4l[526775.861]: config item eth0.tsproc_mode is 0
ptp4l[526775.861]: config item eth0.delay_filter is 1
ptp4l[526775.864]: config item eth0.delay_filter_length is 10
ptp4l[526775.865]: config item eth0.logMinDelayReqInterval is 0
ptp4l[526775.865]: config item eth0.logAnnounceInterval is 1
ptp4l[526775.866]: config item eth0.inhibit_announce is 0
ptp4l[526775.869]: config item eth0.ignore_source_id is 0
ptp4l[526775.870]: config item eth0.announceReceiptTimeout is 3
ptp4l[526775.870]: config item eth0.syncReceiptTimeout is 0
ptp4l[526775.871]: config item eth0.transportSpecific is 0
ptp4l[526775.872]: config item eth0.ignore_transport_specific is 0
ptp4l[526775.874]: config item eth0.G.8275.portDS.localPriority is 128
ptp4l[526775.875]: config item eth0.logSyncInterval is 0
ptp4l[526775.875]: config item eth0.operLogSyncInterval is 0
ptp4l[526775.876]: config item eth0.logMinPdelayReqInterval is 0
ptp4l[526775.879]: config item eth0.operLogPdelayReqInterval is 0
ptp4l[526775.880]: config item eth0.neighborPropDelayThresh is 20000000
ptp4l[526775.880]: config item eth0.min_neighbor_prop_delay is -20000000
ptp4l[526775.881]: config item eth0.delay_response_timeout is 0
ptp4l[526775.881]: config item eth0.asCapable is 1
ptp4l[526775.882]: config item eth0.inhibit_delay_req is 0
ptp4l[526775.885]: config item eth0.udp_ttl is 1
ptp4l[526775.893]: config item (null).dscp_event is 0
ptp4l[526775.896]: config item (null).dscp_general is 0
ptp4l[526775.900]: port 1 (eth0): INITIALIZING to SLAVE on INIT_COMPLETE
ptp4l[526775.902]: config item /var/run/ptp4l.logMinDelayReqInterval is 
0
ptp4l[526775.905]: config item /var/run/ptp4l.logAnnounceInterval is 1
ptp4l[526775.906]: config item /var/run/ptp4l.inhibit_announce is 0
ptp4l[526775.908]: config item /var/run/ptp4l.ignore_source_id is 0
ptp4l[526775.910]: config item /var/run/ptp4l.announceReceiptTimeout is 
0
ptp4l[526775.910]: config item /var/run/ptp4l.syncReceiptTimeout is 0
ptp4l[526775.912]: config item /var/run/ptp4l.transportSpecific is 0
ptp4l[526775.915]: config item /var/run/ptp4l.ignore_transport_specific 
is 0
ptp4l[526775.916]: config item 
/var/run/ptp4l.G.8275.portDS.localPriority is 128
ptp4l[526775.919]: config item /var/run/ptp4l.logSyncInterval is 0
ptp4l[526775.920]: config item /var/run/ptp4l.operLogSyncInterval is 0
ptp4l[526775.920]: config item /var/run/ptp4l.logMinPdelayReqInterval is 
0
ptp4l[526775.921]: config item /var/run/ptp4l.operLogPdelayReqInterval 
is 0
ptp4l[526775.923]: config item /var/run/ptp4l.neighborPropDelayThresh is 
20000000
ptp4l[526775.924]: config item /var/run/ptp4l.min_neighbor_prop_delay is 
-20000000
ptp4l[526775.924]: config item /var/run/ptp4l.delay_response_timeout is 
0
ptp4l[526775.925]: config item /var/run/ptp4l.asCapable is 1
ptp4l[526775.927]: config item /var/run/ptp4l.inhibit_delay_req is 0
ptp4l[526775.928]: config item (null).uds_address is '/var/run/ptp4l'
ptp4l[526775.929]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on 
INIT_COMPLETE
ptp4l[526775.930]: config item /var/run/ptp4lro.logMinDelayReqInterval 
is 0
ptp4l[526775.933]: config item /var/run/ptp4lro.logAnnounceInterval is 1
ptp4l[526775.934]: config item /var/run/ptp4lro.inhibit_announce is 0
ptp4l[526775.934]: config item /var/run/ptp4lro.ignore_source_id is 0
ptp4l[526775.935]: config item /var/run/ptp4lro.announceReceiptTimeout 
is 0
ptp4l[526775.936]: config item /var/run/ptp4lro.syncReceiptTimeout is 0
ptp4l[526775.937]: config item /var/run/ptp4lro.transportSpecific is 0
ptp4l[526775.937]: config item 
/var/run/ptp4lro.ignore_transport_specific is 0
ptp4l[526775.938]: config item 
/var/run/ptp4lro.G.8275.portDS.localPriority is 128
ptp4l[526775.939]: config item /var/run/ptp4lro.logSyncInterval is 0
ptp4l[526775.940]: config item /var/run/ptp4lro.operLogSyncInterval is 0
ptp4l[526775.941]: config item /var/run/ptp4lro.logMinPdelayReqInterval 
is 0
ptp4l[526775.943]: config item /var/run/ptp4lro.operLogPdelayReqInterval 
is 0
ptp4l[526775.944]: config item /var/run/ptp4lro.neighborPropDelayThresh 
is 20000000
ptp4l[526775.944]: config item /var/run/ptp4lro.min_neighbor_prop_delay 
is -20000000
ptp4l[526775.945]: config item /var/run/ptp4lro.delay_response_timeout 
is 0
ptp4l[526775.946]: config item /var/run/ptp4lro.asCapable is 1
ptp4l[526775.948]: config item /var/run/ptp4lro.inhibit_delay_req is 0
ptp4l[526775.949]: config item (null).uds_address is '/var/run/ptp4l'
ptp4l[526775.950]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING 
on INIT_COMPLETE
ptp4l[526775.952]: port 1 (eth0): received link status notification
ptp4l[526775.955]: interface index 4 is up
ptp4l[526776.598]: port 1 (eth0): setting asCapable
ptp4l[526776.614]: port 1 (eth0): delay timeout
ptp4l[526776.752]: port 1 (eth0): new foreign master 
304511.fffe.0ff048-1
ptp4l[526776.928]: port 1 (eth0): delay timeout
ptp4l[526777.908]: port 1 (eth0): delay timeout
ptp4l[526777.945]: port 1 (eth0): delay timeout
ptp4l[526779.134]: port 1 (eth0): delay timeout
ptp4l[526779.616]: port 1 (eth0): delay timeout
ptp4l[526780.752]: selected best master clock 304511.fffe.0ff048
ptp4l[526780.842]: port 1 (eth0): delay timeout
ptp4l[526781.343]: port 1 (eth0): delay timeout
ptp4l[526782.171]: port 1 (eth0): delay timeout
ptp4l[526782.173]: delay filtered 17998 raw 17998
ptp4l[526782.235]: port 1 (eth0): announce timeout
ptp4l[526782.235]: config item eth0.udp_ttl is 1
ptp4l[526782.238]: config item (null).dscp_event is 0
ptp4l[526782.239]: config item (null).dscp_general is 0
ptp4l[526782.239]: selected local clock 304511.fffe.0e6de7 as best 
master
ptp4l[526783.276]: port 1 (eth0): delay timeout
ptp4l[526783.278]: delay filtered 18586 raw 18586
ptp4l[526783.599]: master offset 2393871961236 s0 freq -1953122 path 
delay 18586
ptp4l[526784.325]: port 1 (eth0): delay timeout
ptp4l[526784.327]: delay filtered 18723 raw 18860
ptp4l[526784.601]: master offset 2393871950451 s1 freq -1953124 path 
delay 18723
ptp4l[526784.753]: selected best master clock 304511.fffe.0ff048
ptp4l[526786.165]: port 1 (eth0): delay timeout
ptp4l[526786.167]: delay filtered 17800 raw 17800
ptp4l[526786.599]: master offset 2393871930170 s0 freq -1953124 path 
delay 17800
ptp4l[526787.599]: master offset 2393871919846 s0 freq -1953124 path 
delay 17800
ptp4l[526787.925]: port 1 (eth0): delay timeout
ptp4l[526787.927]: delay filtered 17271 raw 16742
ptp4l[526788.601]: master offset 2393871909811 s1 freq -1953124 path 
delay 17271
ptp4l[526789.267]: port 1 (eth0): delay timeout
ptp4l[526789.599]: master offset 2393871899331 s0 freq -1953124 path 
delay 17271
ptp4l[526790.114]: port 1 (eth0): delay timeout
ptp4l[526790.115]: delay filtered 17726 raw 17726
ptp4l[526790.566]: port 1 (eth0): delay timeout
ptp4l[526790.568]: delay filtered 17763 raw 20202
ptp4l[526790.570]: port 1 (eth0): delay timeout
ptp4l[526790.571]: delay filtered 17800 raw 20062
ptp4l[526790.599]: master offset 2393871887998 s0 freq -1953124 path 
delay 17800
ptp4l[526791.601]: master offset 2393871877754 s1 freq -1953124 path 
delay 17800
ptp4l[526792.507]: port 1 (eth0): delay timeout
ptp4l[526792.600]: clockcheck: clock jumped forward or running faster 
than expected!
ptp4l[526792.600]: master offset 2393871867110 s0 freq -1953124 path 
delay 17800
ptp4l[526793.021]: port 1 (eth0): delay timeout
ptp4l[526793.022]: delay filtered 17763 raw 17334
ptp4l[526793.209]: port 1 (eth0): delay timeout
ptp4l[526793.211]: delay filtered 17800 raw 18344
ptp4l[526793.602]: master offset 2393871856458 s1 freq -1953124 path 
delay 17800
ptp4l[526794.600]: clockcheck: clock jumped forward or running faster 
than expected!
ptp4l[526794.600]: master offset 2393871845490 s0 freq -1953124 path 
delay 17800
ptp4l[526794.704]: port 1 (eth0): delay timeout
ptp4l[526794.705]: delay filtered 17763 raw 15476
ptp4l[526795.598]: port 1 (eth0): delay timeout
ptp4l[526795.600]: delay filtered 17800 raw 20214
ptp4l[526795.603]: master offset 2393871835326 s1 freq -1953124 path 
delay 17800
ptp4l[526796.600]: master offset 2393871824602 s0 freq -1953124 path 
delay 17800
ptp4l[526797.274]: port 1 (eth0): delay timeout
ptp4l[526797.275]: delay filtered 18072 raw 18564
ptp4l[526797.600]: clockcheck: clock jumped forward or running faster 
than expected!
ptp4l[526797.601]: master offset 2393871813694 s0 freq -1953124 path 
delay 18072
ptp4l[526798.581]: port 1 (eth0): delay timeout
ptp4l[526798.583]: delay filtered 18454 raw 20222
ptp4l[526798.602]: master offset 2393871802424 s1 freq -1953124 path 
delay 18454
ptp4l[526799.086]: port 1 (eth0): delay timeout
ptp4l[526799.374]: port 1 (eth0): delay timeout
...

Can someone help me out here?

Kind regards

Maximilian

Re: [Linuxptp-users] Intermittent send delay request failure (tx_timestamp_timeout) w/dp83640

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

On Mon, Dec 06, 2021 at 07:27:54AM -0500, Dan Geer wrote:
> I would like to start with my thanks for the support of the Linux PTP
> Project.  The tools are a great success, and keep getting better!
> 
> I'm developing a custom SBC that works perfectly approximately 90% of the
> time.  However, when the SBC starts or restarts there are cases immediately
> after initialization where ptp4l goes into a repeating cycle of 1) syncing
> to a PTP Grand Master, 2) timing out on the port_delay_request, and 3)
> resetting the failed port.
> 
> My SBC is based on a MPC8360E (NXP PowerQUICC® II Pro Processor with
> ucc_geth MACs) connected to DP83640 PHYTERs.

You want to use the PTP features in the phyters.

First step is to make sure the MAC driver isn't also doing time
stamping.

I don't see PTP support in mainline ucc_geth, but maybe you have a
vendor kernel with time stamping patched in?

Thanks,
Richard

[Linuxptp-users] Intermittent send delay request failure (tx_timestamp_timeout) w/dp83640

[Dan G. <gee...@gm...>]

I would like to start with my thanks for the support of the Linux PTP
Project.  The tools are a great success, and keep getting better!

I'm developing a custom SBC that works perfectly approximately 90% of the
time.  However, when the SBC starts or restarts there are cases immediately
after initialization where ptp4l goes into a repeating cycle of 1) syncing
to a PTP Grand Master, 2) timing out on the port_delay_request, and 3)
resetting the failed port.

My SBC is based on a MPC8360E (NXP PowerQUICC® II Pro Processor with
ucc_geth MACs) connected to DP83640 PHYTERs.  I'm building the entire
distro using yoctoproject's honister release, and Linux 5.10.73 with
the CONFIG PREEMPT RT Patch. I recently upgraded to linuxptp 3.1.1.  Ptp4l
is configured for Hardware timestamps and twoStepFlag = 0.  It appears that
the device drivers support PTP since the time sync works extremely well
most of the time.

I'm in the process of trying to isolate the cause of the failure, but when
everything works most of the time, this can be a big challenge.  I
understand the statement that this is "likely a driver bug", and would like
to know if anyone can point me in the right direction.

Which driver should I focus on?

Is this more likely in the dp83640 PHY layer, or the ucc_geth MAC layer?

And, can you please offer any suggestions on how I might isolate the cause
of the repeating poll timeout? (I might need to provide the fix to the
maintainer)


Thank you in advance for your help!
Dan

Re: [Linuxptp-users] tx_timestamp_timeout problem

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

On Sat, Dec 04, 2021 at 05:07:07PM +0100, Arfaoui Mahdi wrote:
> Hi,
> Can anyone help me please.

As you guessed, it is likely a buggy driver in your A7.
Ask your vendor to fix their driver.

Good luck,
Richard