phc2sys sets the CLOCK_TAI offset of the kernel since commit
commit fefd5b4b05039ea0a0770291b12b0eb931079970
Author: Miroslav Lichvar <mlich...@redhat.com>
Date: Wed Jun 18 15:44:49 2014 +0200
Set TAI offset of system clock.
When synchronizing the system clock and the PTP UTC offset is valid and
traceable, set the TAI offset of the clock to have correct CLOCK_TAI
(which is implemented in the kernel as CLOCK_REALTIME + TAI offset).
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
What I'm missing is:
1. ptp4l in the role of a GM appears to listen for GRANDMASTER_SETTINGS_NP
PTP management messages on the local r/w UDS socket and that's how it
updates its ANNOUNCE message contents. Who is supposed to construct and
send these PTP management messages to the ptp4l GM in a "normal" system?
2. In the case of a slave clock, phc2sys detects that the UTC offset of
the GM is traceable, and updates the CLOCK_TAI offset in the kernel.
But for the GM system, who is supposed to update the CLOCK_TAI offset?
There is some logic in clock.c, namely clock_utc_correct() called
from clock_synchronize():
/* Update TAI-UTC offset of the system clock if valid and traceable. */
if (c->tds.flags & UTC_OFF_VALID && c->tds.flags & TIME_TRACEABLE &&
c->utc_offset_set != utc_offset && c->clkid == CLOCK_REALTIME) {
sysclk_set_tai_offset(utc_offset);
c->utc_offset_set = utc_offset;
}
but mind you, c->clkid is only set to CLOCK_REALTIME if we are
performing software timestamping. So in the general case, ptp4l as GM
does not update the CLOCK_TAI offset, and phc2sys does not, either.
3. Finally, why update the kernel's CLOCK_TAI offset only if the UTC
offset is traceable? I mean, phc2sys in automatic mode sets up the
CLOCK_REALTIME apart by 37 seconds from the PHC anyway, regardless of
whether the UTC offset is traceable or not. Would it not make sense
to set the kernel's TAI offset regardless? As things stand, I think
this behavior is just highly inconsistent. CLOCK_REALTIME certainly
has an offset from the TAI timescale, as set by phc2sys, but
applications cannot detect this.
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
