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

Re: [Linuxptp-users] Unable run ptp4l using Virtual Clock

[Amar B S <ama...@gm...>]

Hi Miroslav,

The code was built on a dev system and I copied binaries into to test
system. Is it required to build on the test system where kernel support is
present ?

Thanks,
Amar

On Mon, Nov 21, 2022 at 1:18 PM Miroslav Lichvar <mli...@re...>
wrote:

> On Mon, Nov 21, 2022 at 12:13:05PM +0530, Amar B S wrote:
> > When I run ptp4l it's unable to detect the virtual clock and prints out
> the
> > error “phc device mismatch”.
> > After reading through the code I see that *“rtnl_iface_has_vclock” *is
> > failing to detect the virtual clock. Can you please suggest what could be
> > going wrong here? We are using CentOS 7 with
> > *“kernel-ml-6.0.8-1.el7.elrepo.x86_64”*
>
> Were the corresponding development files of the kernel available when
> linuxptp was built? In the build log you should see -DHAVE_VCLOCKS.
>
> --
> Miroslav Lichvar
>
>

Re: [Linuxptp-users] Unable run ptp4l using Virtual Clock

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

On Mon, Nov 21, 2022 at 12:13:05PM +0530, Amar B S wrote:
> When I run ptp4l it's unable to detect the virtual clock and prints out the
> error “phc device mismatch”.
> After reading through the code I see that *“rtnl_iface_has_vclock” *is
> failing to detect the virtual clock. Can you please suggest what could be
> going wrong here? We are using CentOS 7 with
> *“kernel-ml-6.0.8-1.el7.elrepo.x86_64”*

Were the corresponding development files of the kernel available when
linuxptp was built? In the build log you should see -DHAVE_VCLOCKS.

-- 
Miroslav Lichvar

[Linuxptp-users] Unable run ptp4l using Virtual Clock

[Amar B S <ama...@gm...>]

Hi LinuxPtp Community,

We are trying to run multiple instances of ptp4l on the same interface
using the virtual PHC clock feature that was submitted to linuxptp.
We are using the master branch of linuxPTP and kernel 6.0.8. I have created
virtual clocks using the command “echo 2 >  /sys/class/ptp/ptp2/n_vclocks”,
and provided the phc_index in the config file.

When I run ptp4l it's unable to detect the virtual clock and prints out the
error “phc device mismatch”.
After reading through the code I see that *“rtnl_iface_has_vclock” *is
failing to detect the virtual clock. Can you please suggest what could be
going wrong here? We are using CentOS 7 with
*“kernel-ml-6.0.8-1.el7.elrepo.x86_64”*





LOGS:

*[root@supermicrodu1 ~]# ./ptp4l -f /etc/sysconfig/config_ptp.conf -i
sriov2  -m 2 -H -l 6 -s --slave_event_monitor=/tmp/pmc*

*option slaveOnly is deprecated, please use clientOnly instead*

*ptp4l[166163.457]: selected /dev/ptp8 as PTP clock*

*ptp4l[166163.457]: port 1 (sriov2): PHC device mismatch*

*ptp4l[166163.457]: port 1 (sriov2): /dev/ptp8 requested, ptp2 attached*

*ptp4l[166163.457]: failed to open port sriov2*





Thanks,
Amar

Re: [Linuxptp-users] Current Linuxptp not compiling on compilers without enforced std version

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

On Wed, Nov 16, 2022 at 01:54:52PM +0100, Jakub Raczyński wrote:

>  arm-linux-gcc -Wall -DVER=3.1-00176-ga115563-dirty -D_GNU_SOURCE -DHAVE_CLOCK_ADJTIME -DHAVE_POSIX_SPAWN -DHAVE_ONESTEP_SYNC -c -o tlv.o tlv.c 
> tlv.c: In function ‘mgt_post_recv’: 
> tlv.c:374:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode 
> for (int i = 0; i < umtn->actual_table_size; i++) { 

Yeah that snuck past the review.  Local variables belong at top of
function.  Please submit patch to fix.

Thanks,
Richard

[Linuxptp-users] Current Linuxptp not compiling on compilers without enforced std version

[Jakub R. <j.r...@el...>]

 Greetings, 



 I was trying to compile linuxptp from newest source (repo cloned today) and i got following error: 



 arm-linux-gcc -Wall -DVER=3.1-00176-ga115563-dirty -D_GNU_SOURCE -DHAVE_CLOCK_ADJTIME -DHAVE_POSIX_SPAWN -DHAVE_ONESTEP_SYNC -c -o tlv.o tlv.c 
tlv.c: In function ‘mgt_post_recv’: 
tlv.c:374:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode 
for (int i = 0; i < umtn->actual_table_size; i++) { 
^ 
tlv.c:374:3: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code 
tlv.c: In function ‘mgt_pre_send’: 
tlv.c:551:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode 
for (int i = 0; i < umtn->actual_table_size; i++) { 
^ 



 I am using arm-linux-gcc version 4.9.4. 

 Enforcing C99/C11 by adding flag from the warning fixes the issue on this compiler. 
 I leave that to you whether you prefer enforcing C99/C11 or older compilers compliance. 



 Best regards 
Jakub Raczynski 

Re: [Linuxptp-users] PHC not being updated correctly

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

On 11/15/2022 8:51 AM, prathosh shastry wrote:
> Hello Jacob,
> 
> Thanks for your reply. Yes, I can use the phc_ctl set and I see the phc 
> being updated to the current time of the day. If I try phc get, again I 
> see only the nSec bits being updated. Looks like it is something to do 
> with the drivers.
> 
> Regards
> Prathosh
> 

It is most likely a bug in the frequency calculations done in the MACB 
driver. I looked at the driver code and it seems suspicious in how it 
has separated seconds from the small set of nanoseconds.

I assume that if you wait a while it just keeps rolling over the 
nanoseconds?

At this point I'd suggest reaching out to netdev and cc'ing the driver 
maintainers for the MACB drivers in the MAINTAINERS file of Linux. 
Alternatively you could reach out through whatever other customer 
support methods you have access to.

Thanks,
Jake

Re: [Linuxptp-users] PHC not being updated correctly

[prathosh s. <pra...@gm...>]

Hello Jacob,

Thanks for your reply. Yes, I can use the phc_ctl set and I see the phc
being updated to the current time of the day. If I try phc get, again I see
only the nSec bits being updated. Looks like it is something to do with the
drivers.

Regards
Prathosh

On Tue 15 Nov 2022 at 4:42 p.m., Jacob Keller <jac...@in...>
wrote:

>
>
> On 11/15/2022 4:58 AM, prathosh shastry wrote:
> > Hello team,
> >
> > I had no issue with using software time stamping and also I am able to
> > see the hardware timestamping support by building new kernel. But when I
> > try to use the PHC, I see the PHC clock not being updated correctly. I
> > see only the nSec bits being updated. Here are some of the tests I did.
> >
> > ---------------------
> > /root@sama7g5ek-sd:~# phc_ctl eth0 get/
> >
> > /phc_ctl[60533.796]: clock time is *1.010098874* or Thu Jan  1
> > *00:00:01* 1970/
> >
> > /root@sama7g5ek-sd:~# phc_ctl eth0 get____/
> >
> > /phc_ctl[60536.812]: clock time is *1.015383981* or Thu Jan  1
> > *00:00:01* 1970/
> >
> > /root@sama7g5ek-sd:~# phc_ctl eth0 get____/
> >
> > /phc_ctl[60541.072]: clock time is *1.022850092* or Thu Jan  1
> > *00:00:01* 1970/
> >
>
> Have you tried set to set the time?
>
> At a glance it looks like the MACB driver is doing a bunch of logic that
> should be replaced by a timecounter+cyclecounter.
>
> I can't tell immediately if things are wrong but it looks odd.
>
> > /------------------------/
> >
> > And also, I tried the PHC sanity check, and it fails to get the correct
> > PHC time.
> >
> > -------------------------
> > /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait
> 10.0
> > get____/
> >
> > /phc_ctl[61677.633]: adjusted clock frequency offset to
> > 100000000.000000ppb____/
> >
> > /phc_ctl[61677.638]: set clock time to 0.000000000 or Thu Jan  1
> > 00:00:00 1970____/
> >
> > /phc_ctl[61687.640]: process slept for 10.000000 seconds____/
> >
> > /phc_ctl[61687.641]: clock time is *0.048045447* or Thu Jan  1 00:00:00
> > 1970____/
> >
> > /__ __/
> >
>
> This is asking to set a full 10% faster, and we would expect to see a
> value of 10 but we get a value 100x slower? This could be a frequency bug.
>
> > /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait
> 10.0
> > get____/
> >
> > /phc_ctl[61700.096]: adjusted clock frequency offset to
> > 100000000.000000ppb____/
> >
> > /phc_ctl[61700.101]: set clock time to 0.000000000 or Thu Jan  1
> > 00:00:00 1970____/
> >
> > /phc_ctl[61710.103]: process slept for 10.000000 seconds____/
> >
> > /phc_ctl[61710.104]: clock time is *0.088698838* or Thu Jan  1 00:00:00
> > 1970/
> >
> > It would be great, if you could provide any information on this
> > behaviour. Thanks
> >
> >
>
> Does a set (without the time value) work? This tries to set the clock to
> match the current time of day according to the system.
>
> That is what the MACB driver appears to do during init, so its curious
> you see such a small value.. Unless the particular hardware has a much
> different interval value than the driver expects.
>
> Your best bet would probably be to talk to the maintainer of the
> driver/hardware.
>
> Thanks,
> Jake
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>

Re: [Linuxptp-users] PHC not being updated correctly

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

On 11/15/2022 4:58 AM, prathosh shastry wrote:
> Hello team,
> 
> I had no issue with using software time stamping and also I am able to 
> see the hardware timestamping support by building new kernel. But when I 
> try to use the PHC, I see the PHC clock not being updated correctly. I 
> see only the nSec bits being updated. Here are some of the tests I did.
> 
> ---------------------
> /root@sama7g5ek-sd:~# phc_ctl eth0 get/
> 
> /phc_ctl[60533.796]: clock time is *1.010098874* or Thu Jan  1 
> *00:00:01* 1970/
> 
> /root@sama7g5ek-sd:~# phc_ctl eth0 get____/
> 
> /phc_ctl[60536.812]: clock time is *1.015383981* or Thu Jan  1 
> *00:00:01* 1970/
> 
> /root@sama7g5ek-sd:~# phc_ctl eth0 get____/
> 
> /phc_ctl[60541.072]: clock time is *1.022850092* or Thu Jan  1 
> *00:00:01* 1970/
> 

Have you tried set to set the time?

At a glance it looks like the MACB driver is doing a bunch of logic that 
should be replaced by a timecounter+cyclecounter.

I can't tell immediately if things are wrong but it looks odd.

> /------------------------/
> 
> And also, I tried the PHC sanity check, and it fails to get the correct 
> PHC time.
> 
> -------------------------
> /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0 
> get____/
> 
> /phc_ctl[61677.633]: adjusted clock frequency offset to 
> 100000000.000000ppb____/
> 
> /phc_ctl[61677.638]: set clock time to 0.000000000 or Thu Jan  1 
> 00:00:00 1970____/
> 
> /phc_ctl[61687.640]: process slept for 10.000000 seconds____/
> 
> /phc_ctl[61687.641]: clock time is *0.048045447* or Thu Jan  1 00:00:00 
> 1970____/
> 
> /__ __/
> 

This is asking to set a full 10% faster, and we would expect to see a 
value of 10 but we get a value 100x slower? This could be a frequency bug.

> /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0 
> get____/
> 
> /phc_ctl[61700.096]: adjusted clock frequency offset to 
> 100000000.000000ppb____/
> 
> /phc_ctl[61700.101]: set clock time to 0.000000000 or Thu Jan  1 
> 00:00:00 1970____/
> 
> /phc_ctl[61710.103]: process slept for 10.000000 seconds____/
> 
> /phc_ctl[61710.104]: clock time is *0.088698838* or Thu Jan  1 00:00:00 
> 1970/
> 
> It would be great, if you could provide any information on this 
> behaviour. Thanks
> 
> 

Does a set (without the time value) work? This tries to set the clock to 
match the current time of day according to the system.

That is what the MACB driver appears to do during init, so its curious 
you see such a small value.. Unless the particular hardware has a much 
different interval value than the driver expects.

Your best bet would probably be to talk to the maintainer of the 
driver/hardware.

Thanks,
Jake

Re: [Linuxptp-users] PHC not being updated correctly

[prathosh s. <pra...@gm...>]

Hello Miroslav, thanks for your reply. I am using Microchip SAMA7G54, it is
an arm cortex A7-based MPU and it does have a PTP time stamping unit at the
MAC layer.

Enabled the hardware PTP support in the kernel by adding
MACB_CAPS_GEM_HAS_PTP and CONFIG_MACB_USE_HWTIMESTAMP.

Regards
Prathosh

On Tue 15 Nov 2022 at 1:27 p.m., Miroslav Lichvar <mli...@re...>
wrote:

> On Tue, Nov 15, 2022 at 12:58:53PM +0000, prathosh shastry wrote:
> > Hello team,
> >
> > I had no issue with using software time stamping and also I am able to
> see
> > the hardware timestamping support by building new kernel. But when I try
> to
> > use the PHC, I see the PHC clock not being updated correctly. I see only
> > the nSec bits being updated. Here are some of the tests I did.
> >
> > ---------------------
> > *root@sama7g5ek-sd:~# phc_ctl eth0 get*
> >
> > *phc_ctl[60533.796]: clock time is 1.010098874 or Thu Jan  1 00:00:01
> 1970*
>
> It's most likely a bug in the driver. What hardware are you using?
>
> --
> Miroslav Lichvar
>
>

Re: [Linuxptp-users] PHC not being updated correctly

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

On Tue, Nov 15, 2022 at 12:58:53PM +0000, prathosh shastry wrote:
> Hello team,
> 
> I had no issue with using software time stamping and also I am able to see
> the hardware timestamping support by building new kernel. But when I try to
> use the PHC, I see the PHC clock not being updated correctly. I see only
> the nSec bits being updated. Here are some of the tests I did.
> 
> ---------------------
> *root@sama7g5ek-sd:~# phc_ctl eth0 get*
> 
> *phc_ctl[60533.796]: clock time is 1.010098874 or Thu Jan  1 00:00:01 1970*

It's most likely a bug in the driver. What hardware are you using?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] PHC not being updated correctly

[prathosh s. <pra...@gm...>]

Hello team,

I had no issue with using software time stamping and also I am able to see
the hardware timestamping support by building new kernel. But when I try to
use the PHC, I see the PHC clock not being updated correctly. I see only
the nSec bits being updated. Here are some of the tests I did.

---------------------
*root@sama7g5ek-sd:~# phc_ctl eth0 get*

*phc_ctl[60533.796]: clock time is 1.010098874 or Thu Jan  1 00:00:01 1970*

*root@sama7g5ek-sd:~# phc_ctl eth0 get*

*phc_ctl[60536.812]: clock time is 1.015383981 or Thu Jan  1 00:00:01 1970*

*root@sama7g5ek-sd:~# phc_ctl eth0 get*

*phc_ctl[60541.072]: clock time is 1.022850092 or Thu Jan  1 00:00:01 1970*

*------------------------*

And also, I tried the PHC sanity check, and it fails to get the correct PHC
time.

-------------------------
*root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0
get*

*phc_ctl[61677.633]: adjusted clock frequency offset to 100000000.000000ppb*

*phc_ctl[61677.638]: set clock time to 0.000000000 or Thu Jan  1 00:00:00
1970*

*phc_ctl[61687.640]: process slept for 10.000000 seconds*

*phc_ctl[61687.641]: clock time is 0.048045447 or Thu Jan  1 00:00:00 1970*



*root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0
get*

*phc_ctl[61700.096]: adjusted clock frequency offset to 100000000.000000ppb*

*phc_ctl[61700.101]: set clock time to 0.000000000 or Thu Jan  1 00:00:00
1970*

*phc_ctl[61710.103]: process slept for 10.000000 seconds*

*phc_ctl[61710.104]: clock time is 0.088698838 or Thu Jan  1 00:00:00 1970*

It would be great, if you could provide any information on this behaviour.
Thanks


Warm regards

Prathosh

[Linuxptp-users] (no subject)

[prathosh s. <pra...@gm...>]

Hello team,

I had no issue with using software time stamping and also I am able to see
the hardware timestamping support by building new kernel. But when I try to
use the PHC, I see the PHC clock not being updated correctly. I see only
the nSec bits being updated. Here are some of the tests I did.

---------------------
*root@sama7g5ek-sd:~# phc_ctl eth0 get*

*phc_ctl[60533.796]: clock time is 1.010098874 or Thu Jan  1 00:00:01 1970*

*root@sama7g5ek-sd:~# phc_ctl eth0 get*

*phc_ctl[60536.812]: clock time is 1.015383981 or Thu Jan  1 00:00:01 1970*

*root@sama7g5ek-sd:~# phc_ctl eth0 get*

*phc_ctl[60541.072]: clock time is 1.022850092 or Thu Jan  1 00:00:01 1970*

*------------------------*

And also, I tried the PHC sanity check, and it fails to get the correct PHC
time.

-------------------------
*root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0
get*

*phc_ctl[61677.633]: adjusted clock frequency offset to 100000000.000000ppb*

*phc_ctl[61677.638]: set clock time to 0.000000000 or Thu Jan  1 00:00:00
1970*

*phc_ctl[61687.640]: process slept for 10.000000 seconds*

*phc_ctl[61687.641]: clock time is 0.048045447 or Thu Jan  1 00:00:00 1970*



*root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0
get*

*phc_ctl[61700.096]: adjusted clock frequency offset to 100000000.000000ppb*

*phc_ctl[61700.101]: set clock time to 0.000000000 or Thu Jan  1 00:00:00
1970*

*phc_ctl[61710.103]: process slept for 10.000000 seconds*

*phc_ctl[61710.104]: clock time is 0.088698838 or Thu Jan  1 00:00:00 1970*

It would be great, if you could provide any information on this behaviour.
Thanks


Warm regards

Prathosh

[Linuxptp-users] PTP with HSR

[Sebastian A. S. <bi...@li...>]

Hi,

I'm looking into using linuxptp over an HSR interface provided by the
linux HSR implementation. Has this been discussed here before? I
couldn't find any traces…

My understanding is that linuxptp has to act as a transparent clock and
needs to be aware of the two slave ports. The PTP packets need to have
a HSR frame around them.

Sebastian

[Linuxptp-users] Regarding phc2sys

[sarveshwar k <sar...@gm...>]

Hi All,

I. I have PHC running slower/jumping backward when I try to sync PHC to
System Time using below command:
*phc2sys -s CLOCK_REALTIME -c /dev/ptp0 -m*

II. And one more usage of phc2sys I am doing is (to sync system time using
pps and ptp0):
*phc2sys -d /dev/pps0 -s /dev/ptp0 -c CLOCK_REALTIME*
Here I am getting an error of PPS out of Sync with PHC.

Can anyone please help how to resolve this?

Re: [Linuxptp-users] [Linuxptp-devel] Wrong Update of PHC time.

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

On Fri, Nov 04, 2022 at 03:36:14AM +0000, ramesh t via Linuxptp-devel wrote:
> Hi,
> 
> Observed a issue where PTP is running is fine with single digit rms value. Due to error in switch/GM, there is wrong time update towards the ptp4l. This results in wrong update on PHC time on the NIC. PHC time seems to be set to 1970 or 2070 timeframe may be due to error condition in ptp4l. Though the GM or switch starts sending proper time in sometime, PHC time on the NIC doesn't get corrected.
> 
> Quick Question:
> Is there any fix provided in the latest code which handles case where GM/Switch send wrong time momentarily?
> After GM/switch recovered to proper time, is there a way for PHC to converge faster to proper time?

Please don't send such questions to the -devel list.

The -devel list is for patches only.

Thanks,
Richard

[Linuxptp-users] Wrong Update of PHC time.

[ramesh t <ram...@ya...>]

Hi,

Observed a issue where PTP is running is fine with single digit rms value. Due to error in switch/GM, there is wrong time update towards the ptp4l. This results in wrong update on PHC time on the NIC. PHC time seems to be set to 1970 or 2070 timeframe may be due to error condition in ptp4l. Though the GM or switch starts sending proper time in sometime, PHC time on the NIC doesn't get corrected.

Quick Question:
Is there any fix provided in the latest code which handles case where GM/Switch send wrong time momentarily?
After GM/switch recovered to proper time, is there a way for PHC to converge faster to proper time?

Please suggest.

regards,
Ramesh

Re: [Linuxptp-users] Fw: clock_gettime() and clock_id (Nemo Crypto)

[Nemo C. <nem...@gm...>]

 Yes the bracket has the monotonic time. The time wasn't showing the same because I rebooted it before getting the logs.. Please see now.


root@vshanmu:~# pmc -u -s /var/run/ptp4l-eth0-slave -b 0 "GET TIME_STATUS_NP"
sending: GET TIME_STATUS_NP
    02f052.fffe.440233-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
        master_offset              -34
        ingress_time               316315893205115170
        cumulativeScaledRateOffset +0.000000000
        scaledLastGmPhaseChange    0
        gmTimeBaseIndicator        0
        lastGmPhaseChange          0x0000'0000000000000000.0000
        gmPresent                  true
        gmIdentity                 02f052.fffe.440240
root@vshanmu:~# ./out
MONOTONIC:47244.423291425
REALTIME:316315897.62804846
TAI:316315897.62811430
Sleep 1sec
MONOTONIC:47245.423488082
REALTIME:316315898.62923039
TAI:316315898.62929194
Sleep 1sec
MONOTONIC:47246.423585463
REALTIME:316315899.63017930
TAI:316315899.63020838
Sleep 1sec
MONOTONIC:47247.423675860
REALTIME:316315900.63107994
TAI:316315900.63113771
Sleep 1sec
MONOTONIC:47248.423769407
REALTIME:316315901.63201428
TAI:316315901.63207012
Sleep 1sec
root@vshanmu:~# tail -f /var/log/ptp.log
ptp4l[47261.065]: master offset        132 s2 freq  +18654 path delay     16104
phc2sys[47261.505]: CLOCK_REALTIME phc offset       138 s2 freq  +18667 delay   1073
ptp4l[47262.090]: master offset       4772 s2 freq  +23333 path delay     16104
phc2sys[47262.505]: CLOCK_REALTIME phc offset      2066 s2 freq  +20636 delay   1068
ptp4l[47263.115]: master offset       3630 s2 freq  +23623 path delay     16261
phc2sys[47263.505]: CLOCK_REALTIME phc offset      4872 s2 freq  +24062 delay   1069
ptp4l[47264.140]: master offset     -10701 s2 freq  +10381 path delay     16261
phc2sys[47264.505]: CLOCK_REALTIME phc offset      -402 s2 freq  +20250 delay   1062
ptp4l[47265.165]: master offset      -1963 s2 freq  +15908 path delay     15798
phc2sys[47265.506]: CLOCK_REALTIME phc offset     -8392 s2 freq  +12139 delay   1072
ptp4l[47266.190]: master offset       4193 s2 freq  +21476 path delay     15798
phc2sys[47266.506]: CLOCK_REALTIME phc offset     -2873 s2 freq  +15140 delay   1069
^C
root@vshanmu:~# ps -ef |grep ptp4l
  698 root      0:09 ptp4l -i eth0 -f /usr/share/ptp4l/ptp4l-eth0-slave.conf -s -m
  699 root      0:03 phc2sys -s eth0 -z /var/run/ptp4l-eth0-slave -w -m
 1191 root      0:00 grep ptp4l
root@cavs:~#

    On Monday, 31 October, 2022 at 10:12:01 am GMT-4, Miroslav Lichvar <mli...@re...> wrote:  
 
 On Mon, Oct 31, 2022 at 02:00:28PM +0000, Nemo Crypto wrote:
> MONOTONIC:964.921879908
> REALTIME:316260827.761696659
> TAI:316260827.761702962
> 
> During this time, at least, I was expecting that the phc2sys phc offset would show the jump in offset which is not the case..
> phc2sys[44.221]: CLOCK_REALTIME phc offset       909 s2 freq  +17596 delay   1071
> ptp4l[44.283]: master offset       1156 s2 freq  +18362 path delay     14498
> phc2sys[45.221]: CLOCK_REALTIME phc offset      1651 s2 freq  +18610 delay   1041
> ptp4l[45.308]: master offset        766 s2 freq  +18319 path delay     14498
> phc2sys[46.221]: CLOCK_REALTIME phc offset      1346 s2 freq  +18801 delay   1069
> ptp4l[46.333]: master offset       -305 s2 freq  +17478 path delay     14498
> phc2sys[47.221]: CLOCK_REALTIME phc offset       123 s2 freq  +1798
> Can you please help explaining this behavior?

The timestamps printed by ptp4l and phc2sys in brackets is the
monotonic time, which doesn't match the 964 above. Are you running the
commands on the same machine?

-- 
Miroslav Lichvar

  

Re: [Linuxptp-users] Fw: clock_gettime() and clock_id (Nemo Crypto)

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

On Mon, Oct 31, 2022 at 02:00:28PM +0000, Nemo Crypto wrote:
> MONOTONIC:964.921879908
> REALTIME:316260827.761696659
> TAI:316260827.761702962
> 
> During this time, at least, I was expecting that the phc2sys phc offset would show the jump in offset which is not the case..
> phc2sys[44.221]: CLOCK_REALTIME phc offset       909 s2 freq  +17596 delay   1071
> ptp4l[44.283]: master offset       1156 s2 freq  +18362 path delay     14498
> phc2sys[45.221]: CLOCK_REALTIME phc offset      1651 s2 freq  +18610 delay   1041
> ptp4l[45.308]: master offset        766 s2 freq  +18319 path delay     14498
> phc2sys[46.221]: CLOCK_REALTIME phc offset      1346 s2 freq  +18801 delay   1069
> ptp4l[46.333]: master offset       -305 s2 freq  +17478 path delay     14498
> phc2sys[47.221]: CLOCK_REALTIME phc offset       123 s2 freq  +1798
> Can you please help explaining this behavior?

The timestamps printed by ptp4l and phc2sys in brackets is the
monotonic time, which doesn't match the 964 above. Are you running the
commands on the same machine?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Fw: clock_gettime() and clock_id (Nemo Crypto)

[Nemo C. <nem...@gm...>]

 Hi Chris & Miroslav,

Yes, you both are correct. I misunderstood my observation. sorry for the confusion.

Both CLOCK_REALTIME(UTC) & CLOCK_TAI are only differ by the UTC offset. CLOCK_REALTIME do not experience jump due to timezone change or daylight savings adjustment change. This part is clear now and thanks for your explanations.

Please clarify this behavior,
Currently, the local hw clock (PHC) is getting synchronized by gPTP acting as gPTP SLAVE by the remote Master. And the local system clock is synchronized using phc2sys service. During this time, I thought the local clock time adjustment will not be allowed as the time is updated automatically. But Linux allows to change the system time by the user. I use the below command to change the system time.

date +%T -s "10:13:13"
When I do this change, CLOCK_REALTIME reflects the change. 

This is the sequence of operation, (Please note my system is using 1980s time)

1. Read CLOCK_REALTIME using the simple c program writted and executed.. before the manual time adjustment:
MONOTONIC:915.553454615
REALTIME:316268291.560535004
TAI:316268291.560541365
Sleep 1sec
MONOTONIC:916.553630100
REALTIME:316268292.560633633
TAI:316268292.560636661
Sleep 1sec
MONOTONIC:917.553720556
REALTIME:316268293.560722238
TAI:316268293.560725153
2. adj the time manually using the date command - date +%T -s "10:13:13"

3. CLOCK_REALTIME after the manual time adjustment to "10:13:13"

MONOTONIC:962.891684609
REALTIME:316260825.731500536
TAI:316260825.731503804
Sleep 1sec
MONOTONIC:963.902189222
REALTIME:316260826.742004746
TAI:316260826.742008167
Sleep 1sec
MONOTONIC:964.921879908
REALTIME:316260827.761696659
TAI:316260827.761702962

During this time, at least, I was expecting that the phc2sys phc offset would show the jump in offset which is not the case..
phc2sys[44.221]: CLOCK_REALTIME phc offset       909 s2 freq  +17596 delay   1071
ptp4l[44.283]: master offset       1156 s2 freq  +18362 path delay     14498
phc2sys[45.221]: CLOCK_REALTIME phc offset      1651 s2 freq  +18610 delay   1041
ptp4l[45.308]: master offset        766 s2 freq  +18319 path delay     14498
phc2sys[46.221]: CLOCK_REALTIME phc offset      1346 s2 freq  +18801 delay   1069
ptp4l[46.333]: master offset       -305 s2 freq  +17478 path delay     14498
phc2sys[47.221]: CLOCK_REALTIME phc offset       123 s2 freq  +1798
Can you please help explaining this behavior?


    On Monday, 31 October, 2022 at 03:25:41 am GMT-4, Miroslav Lichvar <mli...@re...> wrote:  
 
 On Sun, Oct 30, 2022 at 05:50:00PM +0000, Nemo Crypto wrote:
>  Thank you Chris, this answers my question.
> 
> I used CLOCK_REALTIME and observed the time jumping according to the timezone change and day light saving adjustment. I think CLOCK_TAI would be the right one to use, I will try this.

CLOCK_REALTIME is supposed to keep time in UTC, not a local timezone.
The only observable time jumps when synchronized should be leap
seconds. If your application is displaying time in a broken-down
format, it might be an issue with calling localtime() instead of
gmtime().

-- 
Miroslav Lichvar

  

Re: [Linuxptp-users] Fw: clock_gettime() and clock_id (Nemo Crypto)

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

On Sun, Oct 30, 2022 at 05:50:00PM +0000, Nemo Crypto wrote:
>  Thank you Chris, this answers my question.
> 
> I used CLOCK_REALTIME and observed the time jumping according to the timezone change and day light saving adjustment. I think CLOCK_TAI would be the right one to use, I will try this.

CLOCK_REALTIME is supposed to keep time in UTC, not a local timezone.
The only observable time jumps when synchronized should be leap
seconds. If your application is displaying time in a broken-down
format, it might be an issue with calling localtime() instead of
gmtime().

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Fw: clock_gettime() and clock_id (Nemo Crypto)

[Nemo C. <nem...@gm...>]

 Thank you Chris, this answers my question.

I used CLOCK_REALTIME and observed the time jumping according to the timezone change and day light saving adjustment. I think CLOCK_TAI would be the right one to use, I will try this.


    On Saturday, 29 October, 2022 at 01:23:13 pm GMT-4, Chris Caudle <ch...@ch...> wrote:  
 
  
> Date: Fri, 28 Oct 2022 20:46:05 +0000 (UTC)

> From: Nemo Crypto <nem...@gm...>

> I am running ptp4l service as the slave in the system that I understand it

> synchronizes the phc (hw clock) to the GMC. I am also running phc2sys which

> synchronizes the system time to the phc clock that is being synchronized by

> ptp4l.

> 

> Now my application needs to use the system time that uses PTP timescale, not

> UTC.


Have you looked at the man page for phc2sys?  If you want to set system time to PTP time rather than UTC then manually give an offset of 0 seconds to phc2sys.

That would cause system time to be off from UTC by 37 seconds, so something to keep in mind.


> . I figured out I should be using clock_gettime(). But confused with

> different clock ids we have - CLOCK_MONOTONIC, CLOCK_REALTIME,

> CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE,

> CLOCK_REALTIME_ALARM, CLOCK_TAI etc.


The recommended time scale for PTP is TAI, so if you want the system time to stay synchronized to UTC, but the application needs to use TAI, then just have the application use CLOCK_TAI.

 https://blog.meinbergglobal.com/2019/04/15/ptp-timescale-and-what-the-heck-is-arb-time/


> Please help me understand the differences of these different clock types?


This is not really PTP specific, that is a general linux/unix/posix programming question.

This Red Hat manual page might be a good start:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/reference_guide/sect-posix_clocks#:~:text=CLOCK_MONOTONIC%20%3A%20represents%20the%20time%20monotonically,CLOCK_MONOTONIC%20as%20the%20POSIX%20clock.


I don't know if it has changed recently, but in the past it was the case that the kernel ignored anything having to do with leap second offsets, and relied on an application keeping track of that and setting the UTC-to-TAI offset correctly if it was needed. So depending on how your system is configured CLOCK_REALTIME and CLOCK_TAI may currently return the same value, even though as of late 2022 they should differ by 37 seconds.

https://askubuntu.com/questions/675622/why-clock-tai-and-clock-realtime-returns-the-same-value/675644#675644


-- 

Chris Caudle

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

Re: [Linuxptp-users] Fw: clock_gettime() and clock_id (Nemo Crypto)

[Chris C. <ch...@ch...>]

> Date: Fri, 28 Oct 2022 20:46:05 +0000 (UTC)
> From: Nemo Crypto <nem...@gm...>
> I am running ptp4l service as the slave in the system that I understand it
> synchronizes the phc (hw clock) to the GMC. I am also running phc2sys which
> synchronizes the system time to the phc clock that is being synchronized by
> ptp4l.
> 
> Now my application needs to use the system time that uses PTP timescale, not
> UTC.

Have you looked at the man page for phc2sys?  If you want to set system time to PTP time 
rather than UTC then manually give an offset of 0 seconds to phc2sys.
That would cause system time to be off from UTC by 37 seconds, so something to keep in 
mind.

> . I figured out I should be using clock_gettime(). But confused with
> different clock ids we have - CLOCK_MONOTONIC, CLOCK_REALTIME,
> CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE,
> CLOCK_REALTIME_ALARM, CLOCK_TAI etc.

The recommended time scale for PTP is TAI, so if you want the system time to stay 
synchronized to UTC, but the application needs to use TAI, then just have the application 
use CLOCK_TAI.
 https://blog.meinbergglobal.com/2019/04/15/ptp-timescale-and-what-the-heck-is-arb-time/[1]

> Please help me understand the differences of these different clock types?

This is not really PTP specific, that is a general linux/unix/posix programming question.
This Red Hat manual page might be a good start:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/
7/html/reference_guide/sect-
posix_clocks#:~:text=CLOCK_MONOTONIC%20%3A%20represents%20the%20time%20mon
otonically,CLOCK_MONOTONIC%20as%20the%20POSIX%20clock.[2]

I don't know if it has changed recently, but in the past it was the case that the kernel 
ignored anything having to do with leap second offsets, and relied on an application 
keeping track of that and setting the UTC-to-TAI offset correctly if it was needed. So 
depending on how your system is configured CLOCK_REALTIME and CLOCK_TAI may 
currently return the same value, even though as of late 2022 they should differ by 37 
seconds.
https://askubuntu.com/questions/675622/why-clock-tai-and-clock-realtime-returns-the-same-value/675644#675644[3]

-- 
Chris Caudle


--------
[1] https://blog.meinbergglobal.com/2019/04/15/ptp-timescale-and-what-the-heck-is-arb-time/
[2] https://access.redhat.com/documentation/en-us/
red_hat_enterprise_linux_for_real_time/7/html/reference_guide/sect-
posix_clocks#:~:text=CLOCK_MONOTONIC%20%3A%20represents%20the%20time%20mon
otonically,CLOCK_MONOTONIC%20as%20the%20POSIX%20clock.
[3] https://askubuntu.com/questions/675622/why-clock-tai-and-clock-realtime-returns-the-same-value/675644#675644

[Linuxptp-users] Fw: clock_gettime() and clock_id

[Nemo C. <nem...@gm...>]

 Hi Richard,

Can you please clarify few of my questions on the system time synchronized by phc2sys?

I am running ptp4l service as the slave in the system that I understand it synchronizes the phc (hw clock) to the GMC.
I am also running phc2sys which synchronizes the system time to the phc clock that is being synchronized by ptp4l. 

Now my application needs to use the system time that uses PTP timescale, not UTC.. I figured out I should be using clock_gettime(). But confused with different clock ids we have - CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_REALTIME_ALARM, CLOCK_TAI etc. 

Please help me understand the differences of these different clock types? which are CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_REALTIME_ALARM, CLOCK_TAI etc. 



Thank you in advance!


   ----- Forwarded message ----- From: Nemo Crypto <nem...@gm...>To: lin...@li... <lin...@li...>Sent: Thursday, 27 October, 2022 at 04:03:58 pm GMT-4Subject: clock_gettime() and clock_id
 Hi All,

Can you please clarify few of my questions on getting the system time synchronized by ptp?

I am running ptp4l service as the slave in the system that I understand it synchronizes the phc (hw clock) to the GMC.
I am also running phc2sys which synchronizes the system time to the phc clock that is being synchronized by ptp4l. 

Now my application needs to use the system time that uses PTP timescale, not UTC.. I figured out I should be using clock_gettime(). But confused with different clock ids we have - CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_REALTIME_ALARM, CLOCK_TAI etc. 

Please help me understand the differences?

Thank you in advance!


  

[Linuxptp-users] reg clock synchronisation

[Akash M. <aka...@s2...>]

Hey all,
i have attached a screen shot and would like to know if something is  
wrong. why does the rms has a huge diiference. how can i know if my  
clocks are synchronised?

[Linuxptp-users] clock_gettime() and clock_id

[Nemo C. <nem...@gm...>]

Hi All,

Can you please clarify few of my questions on getting the system time synchronized by ptp?

I am running ptp4l service as the slave in the system that I understand it synchronizes the phc (hw clock) to the GMC.
I am also running phc2sys which synchronizes the system time to the phc clock that is being synchronized by ptp4l. 

Now my application needs to use the system time that uses PTP timescale, not UTC.. I figured out I should be using clock_gettime(). But confused with different clock ids we have - CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_REALTIME_ALARM, CLOCK_TAI etc. 

Please help me understand the differences?

Thank you in advance!