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

PTP IEEE 1588 stack for Linux

Brought to you by: rcochran

linuxptp-users

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

From: Chris C. <ch...@ch...> - 2022-10-29 17:19:42

> 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

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

From: Nemo C. <nem...@gm...> - 2022-10-30 17:50:12

 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)

From: Miroslav L. <mli...@re...> - 2022-10-31 07:25:55

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)

From: Nemo C. <nem...@gm...> - 2022-10-31 14:00:47

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)

From: Miroslav L. <mli...@re...> - 2022-10-31 14:12:24

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)

From: Nemo C. <nem...@gm...> - 2022-10-31 14:24:30

 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