Thanks Richard, that's useful to know.
Sorry to harp on about this, but in trying to understand I'm looking at a
different and hopefully better master's behaviour when in UTC mode.
This seems to be a bit better, in that it's not claiming TAI. (It's not
even claiming to be traceable).
I note that in addition to the fully expected 'foreign master not using PTP
timescale' message, we also continue to see the 'temporal vortex' log.
Is this intentional - a utc offset less than 36 despite being ARB still
triggers the sanity check? My mental model would be that this asserts we're
not in some spacetime location where TAI:UTC isn't 36-ish, so I'm a little
surprised to see that kick even when not claiming to be TAI.
Would a patch to only sanity check the offset when in ptpTimescale make
sense?
682 >···if (!(c->tds.flags & PTP_TIMESCALE)) {
683 >···>···pr_warning("foreign master not using PTP timescale");
684 >···}
685 *else* if (c->tds.currentUtcOffset < CURRENT_UTC_OFFSET) { // new
'else' here
686 >···>···pr_warning("running in a temporal vortex");
687 >···}
Thanks,
DavidM
PS; FWIW, here's the announce message from a grandmaster I do control in
the lab, when placed in UTC mode:
Frame 176: 106 bytes on wire (848 bits), 106 bytes captured (848 bits)
Ethernet II, Src: EndrunTe_01:0a:a4 (00:0e:fe:01:0a:a4), Dst:
IPv4mcast_01:81 (01:00:5e:00:01:81)
Internet Protocol Version 4, Src: 192.168.2.1 (192.168.2.1), Dst:
ptp-primary.mcast.net (224.0.1.129)
User Datagram Protocol, Src Port: 320, Dst Port: 320
Precision Time Protocol (IEEE1588)
0000 .... = transportSpecific: 0x0
.... 1011 = messageId: Announce Message (0xb)
.... 0010 = versionPTP: 2
messageLength: 64
subdomainNumber: 15
flags: 0x0204
0... .... .... .... = PTP_SECURITY: False
.0.. .... .... .... = PTP profile Specific 2: False
..0. .... .... .... = PTP profile Specific 1: False
.... .0.. .... .... = PTP_UNICAST: False
.... ..1. .... .... = PTP_TWO_STEP: True
.... ...0 .... .... = PTP_ALTERNATE_MASTER: False
.... .... ..0. .... = FREQUENCY_TRACEABLE: False
.... .... ...0 .... = TIME_TRACEABLE: False
.... .... .... 0... = PTP_TIMESCALE: False
.... .... .... .1.. = PTP_UTC_REASONABLE: True
.... .... .... ..0. = PTP_LI_59: False
.... .... .... ...0 = PTP_LI_61: False
correction: 0.000000 nanoseconds
ClockIdentity: 0x000efefffe010aa4
SourcePortID: 1
sequenceId: 130
control: Other Message (5)
logMessagePeriod: 0
originTimestamp (seconds): 0
originTimestamp (nanoseconds): 0
originCurrentUTCOffset: 0
priority1: 0
grandmasterClockClass: 13
grandmasterClockAccuracy: The time is accurate to within 25 ns (0x20)
grandmasterClockVariance: 28336
priority2: 0
grandmasterClockIdentity: 0x000efefffe010aa4
localStepsRemoved: 0
TimeSource: GPS (0x20)
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 17:47, Richard Cochran <richardcoch...@gmail.com>
wrote:
> On Tue, Aug 22, 2017 at 05:05:50PM +1000, David Mirabito wrote:
> > 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.
>
> And for the record, when ptp4l sees timescale ARB, then it assumes
> that the timescale is UTC. That behavior is not standardized, but I
> think it makes sense.
>
> 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
