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
<mlich...@redhat.com> 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
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
