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...@chriscaudle.org> wrote:
> Date: Fri, 28 Oct 2022 20:46:05 +0000 (UTC)
> From: Nemo Crypto <nemo0948.cry...@gmail.com>
> 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
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
