Re: [Linuxptp-users] PTP_Timescale

[Richard C. <ric...@gm...>]

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