Hello Dennys, Miroslav.
I will try your suggestions. Thank you both for the help
BR.
Em qua., 24 de mai. de 2023 às 14:50, Dennis Hagarty (dehagart)
escreveu:
>
> Hi,
>
> Yes, I think so.
>
> The GM will send those values in the Announce message and you pick it up with
> -w
> If it's not,
I managed to assemble a test fixture similar to the embedded system
I am evaluating deploying linuxptp on, as shown on the diagram below.
System clocks of the three main components are working in synchrony
(apparently) and a change on the system clock of the GM is propagated
after a few seconds
Hi,
Yes, I think so.
The GM will send those values in the Announce message and you pick it up with -w
If it's not, you can configure the offset locally on the client end with -O
Regards
Dennis
-Original Message-
From: Miroslav Lichvar
Sent: Wednesday, May 24, 2023 3:51 PM
To: Elder
On Wed, May 24, 2023 at 08:19:37AM -0300, Elder Costa wrote:
> phc latency: 7472
> phc-rt delta: 3739320
> phc-tai delta: 3739035
>
> phc-tai delta is greater than 50 usec !
> TAI offset set in kernel is not correct !
I think you need to set currentUtcOffsetValid and timeTraceable on the
Hello, Dennys, thank you for chiming in.
From my understanding of the documentation, I assumed
the offset would be taken from ptp4l with the '-w' command
argument. Obviously I am missing some config or doing
something wrong I am not figuring out.
I tried some variations but either they
Hi,
I'm not exactly sure what this tool is doing, but most likely explanation for
the difference between those clocks is due to leap second offset (currently 37
seconds).
I believe RT should be UTC, and the PHC should be TAI (37 seconds in front of
TAI). phc2sys should add the offset (either
I am getting the result below with the check_clocks utility.
downloaded from:
https://tsn.readthedocs.io/timesync.html#checking-clocks-synchronization
cve@cve-sbc-flt2:~/work$ sudo ./check_clocks -d enp3s0 -v
Dumping timestamps and deltas
rt tstamp: 1684764184805696608
tai tstamp:
