On Tue, Aug 22, 2017 at 11:58:00AM +1000, David Mirabito wrote:
> We're seeing a case where we're seeing constant 'Temporal Vortex' messages.
> Scanning through this list's archives and reading the code it seems that
> this is related to UTC_Offset being incorrect - in this version <36,
> although should actually be 37 today.
That is right.
> The master is an appliance type, configured to distribute UTC, his announce
> messages look like:
> .... .... ..1. .... = FREQUENCY_TRACEABLE: True
> .... .... ...1 .... = TIME_TRACEABLE: True
> .... .... .... 1... = PTP_TIMESCALE: True
> .... .... .... .1.. = PTP_UTC_REASONABLE: True
> originCurrentUTCOffset: 0
So your GM says that its TAI-UTC offset of zero is correct and the
time is traceable. Brilliant.
> Which results in the local ptp4l instance interpreting it as:
No.
> "GRANDMASTER_SETTINGS_NP" : {
> "currentUtcOffset" : "36",
> "currentUtcOffsetValid" : "0",
> "timeTraceable" : "0",
> "frequencyTraceable" : "0",
> "timeSource" : "0xa0"
> },
>
> This seems to differ slightly from the master's announce, I assume it's
> been through some munging/cleanup/interpretation?
No. These are the settings that would be used if ptp4l ever became
the GM. Notice that the timeSource is local oscillator and
currentUtcOffsetValid is false.
> We also have local clock:
> "TIME_PROPERTIES_DATA_SET" : {
> "currentUtcOffset" : "0",
> "currentUtcOffsetValid" : "1",
> "ptpTimescale" : "1",
> "timeTraceable" : "1",
> "frequencyTraceable" : "1",
> },
>
> And I understand it is this timepropertiesDS.currentUTC which is compared
> to current-utc-offset causing the warning.
Yes.
> Reading 1588 sections 13.3.1, 8.2.4 and 7.2 I get the impression that the
> announce is incorrect in how it goes about advertising UTC: it claims
> PTP_TIMESCALE but also sends time in UTC with an UTCOffset of zero.
Right.
> My reading is that in a perfect world, this master would clear the
> PTP_TIMESCALE bit, placing us in arbitrary timescale and we can just decree
> that the resulting time is UTC (ignoring the offset, if it's ever nonzero?).
No. The currentUtcOffset field stands alone and is independent of the
PTP_TIMESCALE bit.
The GM has two choices WRT to currentUtcOffset and
currentUtcOffsetValid. Either it knows the offset from a global
source like GPS, in which case it sets the correct offset and the
valid flag, or it clears the valid flag, thus marking the valid field
as bogus.
> Given ptp4l 1.8, is there any way we can allow folks to lessen noise in the
> logs?
There is no noise, because the message appears only once. It is a
useful warning to the sysadmin.
> I'm not adverse to patching the code but would rather not mute the message
> altogether as I seems valuable to catch non-intentional weirdness which may
> not happen to fall out nicely.
Right.
> Is this check performed only on BMC selection?
Yes.
> We also see regular new BMC
> selections, always picking the same master, presumably the master is often
> re-evaluating it's accuracy as satellites come in/out of view, etc.
Right.
Thanks,
Richard
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
