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

Re: [Linuxptp-users] Testing PTP synchronization

[Vladimir O. <ol...@gm...>]

On Fri, May 19, 2023 at 11:29:06AM -0300, Elder Costa wrote:
> I need some way to demonstrate synchronization is really
> working. Intended application is an embedded system (ES)
> so I do not need an atomic clock grade precision, only
> that the two ends of the ES run at the same pace and
> events acquired on both ends may be time aligned.

To prove PTP is working, typically you'd expect an oscilloscope with 2
channels probing the PPS output signals from the end stations.

> The ideal setup would involve having some signal generator
> connected to both ends and having them acquire the events,
> timestamp them and the master end logging both ends
> timestamps for offline analysis. However,
> that might involve developing drivers, which I would like to
> avoid, at least for the time being.
> 
> I am thinking of running a simpler, software only approach,
> running a loop on the slave that samples its timestamp
> and sends it to the master that then gets its own timestamp
> and logs both for offline analysis. To avoid reinventing the
> wheel, I would like to know if there is something that does
> that or something similar, in python preferably (C would
> also be fine) that I could use or adapt.

Something like this? https://github.com/vladimiroltean/isochron

[Linuxptp-users] Testing PTP synchronization

[Elder C. <eld...@ti...>]

I need some way to demonstrate synchronization is really
working. Intended application is an embedded system (ES)
so I do not need an atomic clock grade precision, only
that the two ends of the ES run at the same pace and
events acquired on both ends may be time aligned.

The ideal setup would involve having some signal generator
connected to both ends and having them acquire the events,
timestamp them and the master end logging both ends
timestamps for offline analysis. However,
that might involve developing drivers, which I would like to
avoid, at least for the time being.

I am thinking of running a simpler, software only approach,
running a loop on the slave that samples its timestamp
and sends it to the master that then gets its own timestamp
and logs both for offline analysis. To avoid reinventing the
wheel, I would like to know if there is something that does
that or something similar, in python preferably (C would
also be fine) that I could use or adapt.

Thanks in advance.

Re: [Linuxptp-users] phc2sys exists with a Connection Timed Out error

[Bernie E. <be...@gm...>]

We are just what is using what is there in the source code for phc2sys. the
code in question is in the sysoff.c file:

 44 static int sysoff_precise(int fd, int64_t *result, uint64_t *ts)
 45 {
 46         struct ptp_sys_offset_precise pso;
 47         memset(&pso, 0, sizeof(pso));
 48         if (ioctl(fd, PTP_SYS_OFFSET_PRECISE, &pso)) {
 49                 print_ioctl_error("PTP_SYS_OFFSET_PRECISE");
 50                 return -errno;
 51         }
 52         *result = pctns(&pso.sys_realtime) - pctns(&pso.device);
 53         *ts = pctns(&pso.sys_realtime);
 54         return 0;
 55 }

Could I get more clarification on my possible workaround?  Are you saying
that once the timeout occurs the date and time are garbage forever?

tia,bernardo


On Thu, May 18, 2023 at 3:32 PM Jacob Keller <jac...@in...>
wrote:

>
>
> On 5/18/2023 3:16 PM, Bernie Elayda wrote:
> > And more detail on the Ethernet driver used on our NUC(duplicating
> previous
> > info for completeness, too)
> >
> >  Ubutnu 18.04 with kernel 5.4.0-generic
> > System-manufacturer :  Intel(R) Client Systems
> > System-product-name :  NUC10i7FNH
> > Bios-release-date :  04/09/2021
> > Bios-version :  FNCML357.0052.2021.0409.1144
> >
> > 00:1f.6 Ethernet controller: Intel Corporation Device 0d4f
> >         Subsystem: Intel Corporation Device 2081
> >         Flags: bus master, fast devsel, latency 0, IRQ 149
> >         Memory at 96300000 (32-bit, non-prefetchable) [size=128K]
> >         Capabilities: [c8] Power Management version 3
> >         Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >         Kernel driver in use: e1000e
> >         Kernel modules: e1000e
> >
> >
>
> Thanks,
>
> A quick search indicates this appears to be an e1000e-based controller
> by the presence of this define in e1000e/hw.h on a current Linux kernel:
>
> #define E1000_DEV_ID_PCH_CMP_I219_V10>-->-------0x0D4F
>
> At least on mainline kernels I could check, the e1000e_phc_gettimex
> function does not have a failure condition
>
> You're using PTP_SYS_OFFSET_PRECISE ioctl to get the clock time?
>
> The implementation in e1000e_phc_get_syncdevicetime does have a timeout
> condition if it is unable to acquire the timestamp within a delay.
>
> Unfortunately I am unfamiliar with this hardware so I do not know what
> the delay value is or whether it would be safe to change it.
>
> It is likely you occasionally hit the delay and timeout.
>
> I do not think your suggested modification of the SYS_OFFSET_PRECISE
> ioctl is a valid solution since I would expect that accepting the last
> value would be accepting some garbage data and be incorrect....
>

Re: [Linuxptp-users] phc2sys exists with a Connection Timed Out error

[Jacob K. <jac...@in...>]

On 5/18/2023 3:16 PM, Bernie Elayda wrote:
> And more detail on the Ethernet driver used on our NUC(duplicating previous
> info for completeness, too)
> 
>  Ubutnu 18.04 with kernel 5.4.0-generic
> System-manufacturer :  Intel(R) Client Systems
> System-product-name :  NUC10i7FNH
> Bios-release-date :  04/09/2021
> Bios-version :  FNCML357.0052.2021.0409.1144
> 
> 00:1f.6 Ethernet controller: Intel Corporation Device 0d4f
>         Subsystem: Intel Corporation Device 2081
>         Flags: bus master, fast devsel, latency 0, IRQ 149
>         Memory at 96300000 (32-bit, non-prefetchable) [size=128K]
>         Capabilities: [c8] Power Management version 3
>         Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Kernel driver in use: e1000e
>         Kernel modules: e1000e
> 
> 

Thanks,

A quick search indicates this appears to be an e1000e-based controller
by the presence of this define in e1000e/hw.h on a current Linux kernel:

#define E1000_DEV_ID_PCH_CMP_I219_V10>-->-------0x0D4F

At least on mainline kernels I could check, the e1000e_phc_gettimex
function does not have a failure condition

You're using PTP_SYS_OFFSET_PRECISE ioctl to get the clock time?

The implementation in e1000e_phc_get_syncdevicetime does have a timeout
condition if it is unable to acquire the timestamp within a delay.

Unfortunately I am unfamiliar with this hardware so I do not know what
the delay value is or whether it would be safe to change it.

It is likely you occasionally hit the delay and timeout.

I do not think your suggested modification of the SYS_OFFSET_PRECISE
ioctl is a valid solution since I would expect that accepting the last
value would be accepting some garbage data and be incorrect....

Re: [Linuxptp-users] phc2sys exists with a Connection Timed Out error

[Bernie E. <be...@gm...>]

This is probably more useful than just 'intel NUC i7'::

System-manufacturer :  Intel(R) Client Systems
System-product-name :  NUC10i7FNH
Bios-release-date :  04/09/2021
Bios-version :  FNCML357.0052.2021.0409.1144

Let me know if you need more detailed info.  regards,bernardo

On Thu, May 18, 2023 at 10:26 AM Bernie Gmail <be...@gm...> wrote:

>
> an Intel i7 NUC running Ubutnu 18.04 with kernel 5.4.0-generic
>
> Sent from fruit phone
>
> > On May 18, 2023, at 10:20 AM, Jacob Keller <jac...@in...>
> wrote:
> >
> > 
> >
> >> On 5/18/2023 9:14 AM, Bernie Elayda wrote:
> >> Hello, I have an update.  I obtained the HEAD for linuxptp yesterday and
> >> re-ran my setup. Unfortunately, phc2sys failed again with a Connection
> >> timed out:
> >>
> >> phc2sys[470789.265]: CLOCK_REALTIME phc offset       -63 s2 freq   -9645
> >> delay      0
> >> phc2sys[470790.265]: CLOCK_REALTIME phc offset      -797 s2 freq  -10398
> >> delay      0
> >> phc2sys[470791.266]: CLOCK_REALTIME phc offset       524 s2 freq   -9316
> >> delay      0
> >> phc2sys[470792.266]: CLOCK_REALTIME phc offset       598 s2 freq   -9085
> >> delay      0
> >> phc2sys[470793.266]: CLOCK_REALTIME phc offset      -247 s2 freq   -9750
> >> delay      0
> >> phc2sys[470794.267]: CLOCK_REALTIME phc offset       -22 s2 freq   -9599
> >> delay      0
> >> phc2sys[470795.267]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out
> >>
> >> Is there something I can do to troubleshoot this?  Our application
> needs to
> >> run for days.  My solution is to modify the phc2sys's sysoff_precise to
> >> just use the last pctns and ts result when an ioctl error happens.
> >> when this connection timed out happen, ptp4l is still running.
> >>
> >> regards,bernardo
> >
> > What hardware are you using? I suspect the PHC driver must be returning
> > some error here which is what ultimately causes sys_offset_precise to
> fail.
> >
> >
> > _______________________________________________
> > Linuxptp-users mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>

Re: [Linuxptp-users] phc2sys exists with a Connection Timed Out error

[Bernie G. <be...@gm...>]

an Intel i7 NUC running Ubutnu 18.04 with kernel 5.4.0-generic

Sent from fruit phone

> On May 18, 2023, at 10:20 AM, Jacob Keller <jac...@in...> wrote:
> 
> 
> 
>> On 5/18/2023 9:14 AM, Bernie Elayda wrote:
>> Hello, I have an update.  I obtained the HEAD for linuxptp yesterday and
>> re-ran my setup. Unfortunately, phc2sys failed again with a Connection
>> timed out:
>> 
>> phc2sys[470789.265]: CLOCK_REALTIME phc offset       -63 s2 freq   -9645
>> delay      0
>> phc2sys[470790.265]: CLOCK_REALTIME phc offset      -797 s2 freq  -10398
>> delay      0
>> phc2sys[470791.266]: CLOCK_REALTIME phc offset       524 s2 freq   -9316
>> delay      0
>> phc2sys[470792.266]: CLOCK_REALTIME phc offset       598 s2 freq   -9085
>> delay      0
>> phc2sys[470793.266]: CLOCK_REALTIME phc offset      -247 s2 freq   -9750
>> delay      0
>> phc2sys[470794.267]: CLOCK_REALTIME phc offset       -22 s2 freq   -9599
>> delay      0
>> phc2sys[470795.267]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out
>> 
>> Is there something I can do to troubleshoot this?  Our application needs to
>> run for days.  My solution is to modify the phc2sys's sysoff_precise to
>> just use the last pctns and ts result when an ioctl error happens.
>> when this connection timed out happen, ptp4l is still running.
>> 
>> regards,bernardo
> 
> What hardware are you using? I suspect the PHC driver must be returning
> some error here which is what ultimately causes sys_offset_precise to fail.
> 
> 
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] phc2sys exists with a Connection Timed Out error

[Jacob K. <jac...@in...>]

On 5/18/2023 9:14 AM, Bernie Elayda wrote:
> Hello, I have an update.  I obtained the HEAD for linuxptp yesterday and
> re-ran my setup. Unfortunately, phc2sys failed again with a Connection
> timed out:
> 
> phc2sys[470789.265]: CLOCK_REALTIME phc offset       -63 s2 freq   -9645
> delay      0
> phc2sys[470790.265]: CLOCK_REALTIME phc offset      -797 s2 freq  -10398
> delay      0
> phc2sys[470791.266]: CLOCK_REALTIME phc offset       524 s2 freq   -9316
> delay      0
> phc2sys[470792.266]: CLOCK_REALTIME phc offset       598 s2 freq   -9085
> delay      0
> phc2sys[470793.266]: CLOCK_REALTIME phc offset      -247 s2 freq   -9750
> delay      0
> phc2sys[470794.267]: CLOCK_REALTIME phc offset       -22 s2 freq   -9599
> delay      0
> phc2sys[470795.267]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out
> 
> Is there something I can do to troubleshoot this?  Our application needs to
> run for days.  My solution is to modify the phc2sys's sysoff_precise to
> just use the last pctns and ts result when an ioctl error happens.
> when this connection timed out happen, ptp4l is still running.
> 
> regards,bernardo

What hardware are you using? I suspect the PHC driver must be returning
some error here which is what ultimately causes sys_offset_precise to fail.

Re: [Linuxptp-users] phc2sys exists with a Connection Timed Out error

[Bernie E. <be...@gm...>]

Hello, I have an update.  I obtained the HEAD for linuxptp yesterday and
re-ran my setup. Unfortunately, phc2sys failed again with a Connection
timed out:

phc2sys[470789.265]: CLOCK_REALTIME phc offset       -63 s2 freq   -9645
delay      0
phc2sys[470790.265]: CLOCK_REALTIME phc offset      -797 s2 freq  -10398
delay      0
phc2sys[470791.266]: CLOCK_REALTIME phc offset       524 s2 freq   -9316
delay      0
phc2sys[470792.266]: CLOCK_REALTIME phc offset       598 s2 freq   -9085
delay      0
phc2sys[470793.266]: CLOCK_REALTIME phc offset      -247 s2 freq   -9750
delay      0
phc2sys[470794.267]: CLOCK_REALTIME phc offset       -22 s2 freq   -9599
delay      0
phc2sys[470795.267]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out

Is there something I can do to troubleshoot this?  Our application needs to
run for days.  My solution is to modify the phc2sys's sysoff_precise to
just use the last pctns and ts result when an ioctl error happens.
when this connection timed out happen, ptp4l is still running.

regards,bernardo

On Wed, May 17, 2023 at 10:46 AM Bernie Gmail <be...@gm...> wrote:

>
> Thank you! We have the HEAD and re-running our test overnight. Will report
> back on our results tomorrow
>
> regards,bernardo
>
> Sent from fruit phone
>
> > On May 17, 2023, at 3:24 AM, Miroslav Lichvar <mli...@re...>
> wrote:
> >
> > On Fri, May 12, 2023 at 04:28:40PM -0700, Bernie Elayda wrote:
> >> phc2sys will stop but ptp4l will continue to run.  This error appears to
> >> originate from the sysoff_precise function;Doesn't this error just mean
> >> when attempting to read PTP_SYS_OFFSET_PRECISE the kernel was just busy?
> >> Wouldn't it be better to just 'log' the error and continue, or does even
> >> one occurrence of this error mean something is misconfigured in my
> setup?
> >
> > I think this phc2sys issue was fixed after 3.1.1 in git. Please try
> > that and see if it still exits.
> >
> > --
> > Miroslav Lichvar
> >
>

Re: [Linuxptp-users] phc2sys exists with a Connection Timed Out error

[Bernie G. <be...@gm...>]

Thank you! We have the HEAD and re-running our test overnight. Will report back on our results tomorrow

regards,bernardo

Sent from fruit phone

> On May 17, 2023, at 3:24 AM, Miroslav Lichvar <mli...@re...> wrote:
> 
> On Fri, May 12, 2023 at 04:28:40PM -0700, Bernie Elayda wrote:
>> phc2sys will stop but ptp4l will continue to run.  This error appears to
>> originate from the sysoff_precise function;Doesn't this error just mean
>> when attempting to read PTP_SYS_OFFSET_PRECISE the kernel was just busy?
>> Wouldn't it be better to just 'log' the error and continue, or does even
>> one occurrence of this error mean something is misconfigured in my setup?
> 
> I think this phc2sys issue was fixed after 3.1.1 in git. Please try
> that and see if it still exits.
> 
> -- 
> Miroslav Lichvar
> 

Re: [Linuxptp-users] phc2sys exists with a Connection Timed Out error

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

On Fri, May 12, 2023 at 04:28:40PM -0700, Bernie Elayda wrote:
> phc2sys will stop but ptp4l will continue to run.  This error appears to
> originate from the sysoff_precise function;Doesn't this error just mean
> when attempting to read PTP_SYS_OFFSET_PRECISE the kernel was just busy?
> Wouldn't it be better to just 'log' the error and continue, or does even
> one occurrence of this error mean something is misconfigured in my setup?

I think this phc2sys issue was fixed after 3.1.1 in git. Please try
that and see if it still exits.

-- 
Miroslav Lichvar

[Linuxptp-users] Configure PTP4L through multiple NICs

[Chang, B. <Ben...@gt...>]

Hello,

I am trying to have my device receive PTP from a master clock from one NIC and output it through another NIC.
>From my understanding, I need to set  boundary_clock_jbod high in the /etc/ptp4l.conf file. I tried running the command "ptp4l -p /dev/ptp4 -I eno1 -ens801f1 -m" as well as running ptp4l with systemctl restart ptp4l with the previous command as well as "-f /etc/ptp4l.conf -I eno1" after OPTIONS=.

When I view wireshark, my Linux PC isn't outputting any PTP through the other NIC. My linux PC is syncing to the grandmaster.

Is my command correct? Any assistance would be appreciated.

Here is a simple overview of my architecture:
Grandmaster --> RJ45 NIC --> Linux PC --> QSFP --> Other devices

Thank you,
Benjamin Chang

Re: [Linuxptp-users] gPTP and PTP on the same computer

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

On Tue, May 16, 2023 at 01:54:47PM +0000, Eric Decker wrote:

> I have a question related to the question below.  If you use a
> boundary clock between gPTP and PTP, does the PHC have to be shared
> by both NICs?

Yes.

> If each NIC has an independent PHC I think phy2sys has to be used
> two synchronized two instances ptp4l but I am not sure how this
> configuration could work as a boundary clock.

Use phc2sys flag -a and maybe also -r

>From the man page:

       -a     Read  the  clocks  to  synchronize from running ptp4l and follow
              changes in the port states, adjusting the synchronization direc‐
              tion  automatically.  The  system  clock (CLOCK_REALTIME) is not
              synchronized, unless the -r option is also specified.

       -r     Only valid together with the -a  option.  Instructs  phc2sys  to
              also  synchronize the system clock (CLOCK_REALTIME). By default,
              the system clock is not considered as a possible time source. If
              you  want  the  system  clock  to  be  eligible to become a time
              source, specify the -r option twice.
HTH,
Richard

Re: [Linuxptp-users] Software timestamping delay - master offset drift

[Elder C. <eld...@ti...>]

> > > Is it possible to force it to +0 like in the log of the
> > > first run above, the one that synchronizes?
>
> phc_ctl CLOCK_REALTIME freq 0
>

Hello, Miroslav, thank you very much.

BR.

Re: [Linuxptp-users] Software timestamping delay - master offset drift

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

On Tue, May 16, 2023 at 11:04:36AM -0300, Elder Costa wrote:
> > > ptp4l[484.261]: port 1 (enp3s0): new foreign master 0001c0.fffe.1a3cda-1
> > > ptp4l[488.262]: selected best master clock 0001c0.fffe.1a3cda
> > > ptp4l[488.262]: foreign master not using PTP timescale
> > > ptp4l[488.262]: port 1 (enp3s0): LISTENING to UNCALIBRATED on RS_SLAVE
> > > ptp4l[490.263]: master offset -37039670930503 s0 freq      -0 path delay
> > 229600
> > >
> > > ptp4l[17805.578]: port 1 (enp3s0): new foreign master 0001c0.fffe.1a3e8e-1
> > > ptp4l[17809.579]: selected best master clock 0001c0.fffe.1a3e8e
> > > ptp4l[17809.579]: foreign master not using PTP timescale
> > > ptp4l[17809.579]: port 1 (enp3s0): LISTENING to UNCALIBRATED on RS_SLAVE
> > > ptp4l[17810.584]: master offset     159453 s0 freq +100000000 path delay
> >    216530
> > >
> >
> > Where does that initial freq value come from?

It's the current frequency of the clock.

> > Is it possible to force it to +0 like in the log of the
> > first run above, the one that synchronizes?

phc_ctl CLOCK_REALTIME freq 0

-- 
Miroslav Lichvar

Re: [Linuxptp-users] gPTP and PTP on the same computer

[Eric D. <eri...@to...>]

I have a question related to the question below.  If you use a boundary clock between gPTP and PTP, does the PHC have to be shared by both NICs?  What I mean is the PHC is shared by both NICs while each NIC independently timestamps PTP frames using the same PTP hardware clock.

If each NIC has an independent PHC I think phy2sys has to be used two synchronized two instances ptp4l but I am not sure how this configuration could work as a boundary clock.

Eric Decker

-----Original Message-----
From: Richard Cochran <ric...@gm...>
Sent: Tuesday, May 16, 2023 9:42 AM
To: Fueloep, Tamas <tam...@si...>
Cc: lin...@li...
Subject: Re: [Linuxptp-users] gPTP and PTP on the same computer

On Tue, May 16, 2023 at 08:35:36AM +0000, Fueloep, Tamas via Linuxptp-users wrote:
> Dear LinuxPTP mailing list participants,
>

> First of all, thank you very much for this amazing software - it
> really makes life easier and it is fun to use. 🙂

"fun to use?"  hahaha that is new!

> I would have a question, because I can't get a grasp on something. I
> have a setup, where multiple sensors are connected to the same
> computer, each of the sensors are connected to a dedicated network
> interface. Some of the sensors are only compatible with gPTP and some
> of them are only with PTP. The default configuration files that come
> with the ptp4linux installation are working perfectly independently,
> but I cannot make the sensors work in a parallel way. I have tried to
> run multiple ptp4l instances and for the PTP I've used the
> 'default.cfg' and for the gPTP the 'automotive-master.cfg'. Obviously
> this does not work as expected, but I am a bit lost on figuring out
> what would be the ideal setup in this case.

> Could you please help me what is the right concept to use in this situation?

You can run ptp4l as a Boundary Clock on multiple interfaces at once, and you can freely mix and match profiles on the different ports.

For example:

    ptp4l -m -q -i eth0 -i eth1

or in a configuration:

   [global]
   # ...

   [eth0]
   # eth0 options...

   [eth1]
   # eth1 options...


The only thing I'm uncertain of is the Automotive Profile.  Most of the configuration options are per-port, but you will probably not set the global option inhibit_delay_req.

See the man page and/or config.c to learn which options are per-port.

Thanks,
Richard


_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
CAUTION: This email originated from outside of TORC's email system. DO NOT click links or open attachments unless you recognize the sender and know the content is safe. Email is NOT a secure means of communication. Handle potentially sensitive information with care.
Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

Re: [Linuxptp-users] gPTP and PTP on the same computer

[Fueloep, T. <tam...@si...>]

Hi Richard,

Thanks for the prompt reply.

Yeah, maybe I am a bit insane, but I find it fun hahaha

I will try what you suggested and report back if it worked. Maybe that's a useful info for others as well.

Thanks,
Tamas

________________________________
From: Richard Cochran <ric...@gm...>
Sent: Tuesday, May 16, 2023 15:42
To: Fueloep, Tamas (SMO SDT TEC SPA TPQ) <tam...@si...>
Cc: lin...@li... <lin...@li...>
Subject: Re: [Linuxptp-users] gPTP and PTP on the same computer

On Tue, May 16, 2023 at 08:35:36AM +0000, Fueloep, Tamas via Linuxptp-users wrote:
> Dear LinuxPTP mailing list participants,
>

> First of all, thank you very much for this amazing software - it
> really makes life easier and it is fun to use. 🙂

"fun to use?"  hahaha that is new!

> I would have a question, because I can't get a grasp on something. I
> have a setup, where multiple sensors are connected to the same
> computer, each of the sensors are connected to a dedicated network
> interface. Some of the sensors are only compatible with gPTP and
> some of them are only with PTP. The default configuration files that
> come with the ptp4linux installation are working perfectly
> independently, but I cannot make the sensors work in a parallel
> way. I have tried to run multiple ptp4l instances and for the PTP
> I've used the 'default.cfg' and for the gPTP the
> 'automotive-master.cfg'. Obviously this does not work as expected,
> but I am a bit lost on figuring out what would be the ideal setup in
> this case.

> Could you please help me what is the right concept to use in this situation?

You can run ptp4l as a Boundary Clock on multiple interfaces at once,
and you can freely mix and match profiles on the different ports.

For example:

    ptp4l -m -q -i eth0 -i eth1

or in a configuration:

   [global]
   # ...

   [eth0]
   # eth0 options...

   [eth1]
   # eth1 options...


The only thing I'm uncertain of is the Automotive Profile.  Most of
the configuration options are per-port, but you will probably not set
the global option inhibit_delay_req.

See the man page and/or config.c to learn which options are per-port.

Thanks,
Richard

Re: [Linuxptp-users] Software timestamping delay - master offset drift

[Elder C. <eld...@ti...>]

> > ptp4l[484.261]: port 1 (enp3s0): new foreign master 0001c0.fffe.1a3cda-1
> > ptp4l[488.262]: selected best master clock 0001c0.fffe.1a3cda
> > ptp4l[488.262]: foreign master not using PTP timescale
> > ptp4l[488.262]: port 1 (enp3s0): LISTENING to UNCALIBRATED on RS_SLAVE
> > ptp4l[490.263]: master offset -37039670930503 s0 freq      -0 path delay
> 229600
> >
> > ptp4l[17805.578]: port 1 (enp3s0): new foreign master 0001c0.fffe.1a3e8e-1
> > ptp4l[17809.579]: selected best master clock 0001c0.fffe.1a3e8e
> > ptp4l[17809.579]: foreign master not using PTP timescale
> > ptp4l[17809.579]: port 1 (enp3s0): LISTENING to UNCALIBRATED on RS_SLAVE
> > ptp4l[17810.584]: master offset     159453 s0 freq +100000000 path delay
>    216530
> >
>
> Where does that initial freq value come from?
>
> Is it possible to force it to +0 like in the log of the
> first run above, the one that synchronizes?
>
> If the latter is possible, but requires code change to be
> tested, where should I look at in the source code?

No hints on this?

Re: [Linuxptp-users] gPTP and PTP on the same computer

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

On Tue, May 16, 2023 at 08:35:36AM +0000, Fueloep, Tamas via Linuxptp-users wrote:
> Dear LinuxPTP mailing list participants,
> 

> First of all, thank you very much for this amazing software - it
> really makes life easier and it is fun to use. 🙂

"fun to use?"  hahaha that is new!

> I would have a question, because I can't get a grasp on something. I
> have a setup, where multiple sensors are connected to the same
> computer, each of the sensors are connected to a dedicated network
> interface. Some of the sensors are only compatible with gPTP and
> some of them are only with PTP. The default configuration files that
> come with the ptp4linux installation are working perfectly
> independently, but I cannot make the sensors work in a parallel
> way. I have tried to run multiple ptp4l instances and for the PTP
> I've used the 'default.cfg' and for the gPTP the
> 'automotive-master.cfg'. Obviously this does not work as expected,
> but I am a bit lost on figuring out what would be the ideal setup in
> this case.

> Could you please help me what is the right concept to use in this situation?

You can run ptp4l as a Boundary Clock on multiple interfaces at once,
and you can freely mix and match profiles on the different ports.

For example:

    ptp4l -m -q -i eth0 -i eth1

or in a configuration:

   [global]
   # ...

   [eth0]
   # eth0 options...

   [eth1]
   # eth1 options...


The only thing I'm uncertain of is the Automotive Profile.  Most of
the configuration options are per-port, but you will probably not set
the global option inhibit_delay_req.

See the man page and/or config.c to learn which options are per-port.

Thanks,
Richard

[Linuxptp-users] gPTP and PTP on the same computer

[Fueloep, T. <tam...@si...>]

Dear LinuxPTP mailing list participants,

First of all, thank you very much for this amazing software - it really makes life easier and it is fun to use. 🙂

I would have a question, because I can't get a grasp on something. I have a setup, where multiple sensors are connected to the same computer, each of the sensors are connected to a dedicated network interface. Some of the sensors are only compatible with gPTP and some of them are only with PTP. The default configuration files that come with the ptp4linux installation are working perfectly independently, but I cannot make the sensors work in a parallel way. I have tried to run multiple ptp4l instances and for the PTP I've used the 'default.cfg' and for the gPTP the 'automotive-master.cfg'. Obviously this does not work as expected, but  I am a bit lost on figuring out what would be the ideal setup in this case.

Could you please help me what is the right concept to use in this situation?

Thank you very much in advance!

Best regards,
Tamas Fulop

Re: [Linuxptp-users] Software timestamping delay - master offset drift

[Elder C. <eld...@ti...>]

> ptp4l[484.261]: port 1 (enp3s0): new foreign master 0001c0.fffe.1a3cda-1
> ptp4l[488.262]: selected best master clock 0001c0.fffe.1a3cda
> ptp4l[488.262]: foreign master not using PTP timescale
> ptp4l[488.262]: port 1 (enp3s0): LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[490.263]: master offset -37039670930503 s0 freq      -0 path delay
229600
>
> ptp4l[17805.578]: port 1 (enp3s0): new foreign master 0001c0.fffe.1a3e8e-1
> ptp4l[17809.579]: selected best master clock 0001c0.fffe.1a3e8e
> ptp4l[17809.579]: foreign master not using PTP timescale
> ptp4l[17809.579]: port 1 (enp3s0): LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[17810.584]: master offset     159453 s0 freq +100000000 path delay
   216530
>

Where does that initial freq value come from?

Is it possible to force it to +0 like in the log of the first run above,
the one
that synchronizes?

If the latter is possible, but requires code change to be tested, where
should I look
at in the source code?

Re: [Linuxptp-users] Question about delay estimation and offset

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

On Fri, May 12, 2023 at 01:54:05PM +0200, Víctor Vázquez Rodríguez wrote:

> We are doing some research based on ptp4l and I noticed that it
> doesn’t perform delay estimation and offset estimation on the same
> cycle.

There is no such thing as a "cycle" in 1588.  Sync/FollowUp and
Delay_Req/Resp are on two independent schedules.

Thanks,
Richard

[Linuxptp-users] phc2sys exists with a Connection Timed Out error

[Bernie E. <be...@gm...>]

Hello,
We are using linuxtptp 3.1.1 on an Intel i7 NUC running Ubutnu 18.04 with
kernel 5.4.0-generic.. We have linuxptp running on the Intel NUC configured
as an OC. Our grandmaster is a 3rd party device. This is all running on a
stand-alone network dedicated to PTP.

Every few hours, our phc2sys will stop with this error:

phc2sys[264069.922]: ioctl PTP_SYS_OFFSET_PRECISE: Connection timed out


phc2sys will stop but ptp4l will continue to run.  This error appears to
originate from the sysoff_precise function;Doesn't this error just mean
when attempting to read PTP_SYS_OFFSET_PRECISE the kernel was just busy?
Wouldn't it be better to just 'log' the error and continue, or does even
one occurrence of this error mean something is misconfigured in my setup?

tia,bernardo

Re: [Linuxptp-users] Question about delay estimation and offset

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

On Fri, May 12, 2023 at 01:54:05PM +0200, Víctor Vázquez Rodríguez wrote:

> We are doing some research based on ptp4l and I noticed that it
> doesn’t perform delay estimation and offset estimation on the same
> cycle. That is, the client updates only the estimated delay when it
> receives a DELAY_RESP and then updates the offset estimation (and
> corrects the clock) when receiving next cycle’s SYNC message. Is
> there a specific reasoning behind this implementation decision?

This is specified in IEEE 1588.

Thanks,
Richard

Re: [Linuxptp-users] Software timestamping delay - master offset drift

[Elder C. <eld...@ti...>]

Em qui., 11 de mai. de 2023 às 21:43, Richard Cochran <
ric...@gm...> escreveu:
> Maybe you have ntpd or systemd timesync or chrony running on the
> client and/or the server?
>
> IIRC Ubuntu enables systemd thing by default, and it is hard to get
> rid of.

I disabled clock sync by NTP before starting these tests because I intended
to
manually alter the clocks as part of the tests. After altering the system
clock
of the master with date -s 'XX.YY', it proceeds from that without syncing
with the real time.

At home it occurred to me the issue could have something to do with
those "time +100000000" in the log. I assumed that could be the value of a
virtual clock of 100MHz that was adjusted to compensate for the delays.
The negative offsets has a lower value. I guessed the positive should
have a higher than +100000000 to lower the delay. What if I switched
the rules of the two Fitlets? That produced the log below. Then I switched
the rules again to see if I reproduced the problem. It turns out it did not.

Notice the freq values are all relatively low and alternate between
positive and negative values. Based on these results, it seems to me
that clock value is really a delta. I had already noticed that some days
ago. Yesterday, all the runs showed that +100000000 and that drift
occurred. Today all the runs show a lower clock and the offset stays
in the tens of us range with some a few hundreds, which is perfect
for my application (1ms is good, 2.5 ms would still be pretty acceptable).

Any ideas?

Here is the log, snipped to avoid clutter.

cve@cve-sbc-flt1:~$ sudo ptp4l -S -m -q --clientOnly=1
--step_threshold=0.001 -i enp3s0
[sudo] password for cve:
ptp4l[483.312]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[483.312]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on
INIT_COMPLETE
ptp4l[483.312]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on
INIT_COMPLETE
ptp4l[484.261]: port 1 (enp3s0): new foreign master 0001c0.fffe.1a3cda-1
ptp4l[488.262]: selected best master clock 0001c0.fffe.1a3cda
ptp4l[488.262]: foreign master not using PTP timescale
ptp4l[488.262]: port 1 (enp3s0): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[490.263]: master offset -37039670930503 s0 freq      -0 path delay
 229600
ptp4l[491.263]: master offset -37039670924487 s0 freq      -0 path delay
 229600
ptp4l[492.264]: master offset -37039670928753 s0 freq      -0 path delay
 232188
ptp4l[493.264]: master offset -37039670917021 s0 freq      -0 path delay
 234777
ptp4l[494.264]: master offset -37039670952779 s0 freq      -0 path delay
 234777
ptp4l[495.264]: master offset -37039670932443 s0 freq      -0 path delay
 239541
ptp4l[496.264]: master offset -37039671053736 s0 freq      -0 path delay
 244305
ptp4l[497.265]: master offset -37039671066600 s0 freq      -0 path delay
 239541
ptp4l[498.265]: master offset -37039670962899 s0 freq      -0 path delay
 239541
ptp4l[499.265]: master offset -37039670952525 s0 freq      -0 path delay
 239065
ptp4l[500.265]: master offset -37039670957832 s0 freq      -0 path delay
 241685
ptp4l[501.265]: master offset -37039671028566 s0 freq      -0 path delay
 242272
ptp4l[502.266]: master offset -37039670976362 s0 freq      -0 path delay
 242272
ptp4l[503.266]: master offset -37039670953205 s0 freq      -0 path delay
 240855
ptp4l[504.266]: master offset -37039671002137 s0 freq      -0 path delay
 240855
ptp4l[505.266]: master offset -37039671039068 s0 freq      -0 path delay
 239652
ptp4l[506.266]: master offset -37039670976926 s1 freq   -2901 path delay
 239652
ptp4l[507.267]: master offset    -103222 s2 freq  -13326 path delay
 239652
ptp4l[507.267]: port 1 (enp3s0): UNCALIBRATED to SLAVE on
MASTER_CLOCK_SELECTED
ptp4l[508.267]: master offset     -89679 s2 freq  -12062 path delay
 239652
ptp4l[509.267]: master offset     -77666 s2 freq  -10938 path delay
 236179
ptp4l[510.267]: master offset     -85815 s2 freq  -11839 path delay
 221372
ptp4l[511.267]: master offset     -40116 s2 freq   -7309 path delay
 221372
ptp4l[512.267]: master offset     -46752 s2 freq   -8019 path delay
 195594
ptp4l[513.268]: master offset     -20651 s2 freq   -5430 path delay
 195101
ptp4l[514.268]: master offset      79506 s2 freq   +4665 path delay
 195101
ptp4l[515.268]: master offset     101894 s2 freq   +7006 path delay
 195101
ptp4l[516.268]: master offset      82552 s2 freq   +5154 path delay
 195101
ptp4l[517.269]: master offset      55103 s2 freq   +2465 path delay
 195101
ptp4l[518.269]: master offset      58935 s2 freq   +2907 path delay
 195101
ptp4l[519.269]: master offset      63706 s2 freq   +3448 path delay
 195594
ptp4l[520.269]: master offset      58163 s2 freq   +2951 path delay
 195594
...
ptp4l[2942.407]: master offset      42215 s2 freq   +1370 path delay
 217699
ptp4l[2943.407]: master offset      29546 s2 freq    +133 path delay
 217699
ptp4l[2944.407]: master offset      -5205 s2 freq   -3348 path delay
 232956
ptp4l[2945.408]: master offset      19100 s2 freq    -898 path delay
 232956
ptp4l[2946.408]: master offset     -75752 s2 freq  -10459 path delay
 232956
ptp4l[2947.408]: master offset      39169 s2 freq   +1072 path delay
 229773
ptp4l[2948.408]: master offset      18187 s2 freq   -1008 path delay
 229773
cve@cve-sbc-flt1:~$

[Linuxptp-users] Question about delay estimation and offset

[Víctor V. R. <vic...@ug...>]

Hi all,

We are doing some research based on ptp4l and I noticed that it doesn’t perform delay estimation and offset estimation on the same cycle. That is, the client updates only the estimated delay when it receives a DELAY_RESP and then updates the offset estimation (and corrects the clock) when receiving next cycle’s SYNC message. Is there a specific reasoning behind this implementation decision?

I actually tried my hand at changing the code locally so it does everything on the same cycle (both delay and offset estimation when receiving a DELAY_RESP) and, although it works, performance is noticeably worse than the base ptp4l implementation. This is the issue I’m trying to figure out.

Best regards,
Víctor

_

Víctor Vázquez
PhD Student
Department of Computer Engineering, Automatics and Robotics (ICAR)
Time-based Technologies and Networks Lab

University of Granada
Calle Periodista Rafael Gómez Montero, 2
CITIC-UGR, Office D1-2
18014 Granada, Spain