Hi Richard,
Thanks for confirming my understanding on why this Announce was fishy. We
suspected as much but couldn't rule out accidentally overlooking something.
Given UTC is explicitly desired/configured in this case it seems our
options are either (ideally) get the master to cease claiming PTP
timescale, then specifying UTC timestamps with an UtcOffset of zero can be
correct (by administrative decree), or just deal with the messages.
You've also set me straight on the use of currentUtcOffset regardless of
PTP or ARB timescales and what the GRANDMASTER_SETTINGS_NP dataset is
actually describing, a red herring in this case.
Thanks again!
- David
This email is subject to copyright and the information in it is
confidential. This e-mail, its content and any files transmitted with it
are intended solely for the addressee/s and may be legally privileged
and/or confidential. Access by any other person other than the addressee/s
is unauthorized without the express written permission of the sender. If
you have received this e-mail in error notify the sender immediately by
email, do not use the email or any attachment or disclose them to any
person, delete the email from your system and destroy all copies you may
have printed. Metamako LP does not guarantee that any email or attachment
is secure or free from viruses or other defects
On 22 August 2017 at 16:13, Richard Cochran <richardcoch...@gmail.com>
wrote:
> 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
