Hi,
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.
The master is an appliance type, configured to distribute UTC, his announce
messages look like:
Frame 3: 106 bytes on wire (848 bits), 106 bytes captured (848 bits)
Ethernet II, Src: Mellanox_xx:xx:xx (7c:fe:90:xx:xx:xx), Dst:
IPv4mcast_01:81 (01:00:5e:00:01:81)
Destination: IPv4mcast_01:81 (01:00:5e:00:01:81)
Source: Mellanox_1a:97:10 (7c:fe:90:xx:xx:xx)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.34.175.100 (10.34.175.100), 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: 0
flags: 0x003c
0... .... .... .... = PTP_SECURITY: False
.0.. .... .... .... = PTP profile Specific 2: False
..0. .... .... .... = PTP profile Specific 1: False
.... .0.. .... .... = PTP_UNICAST: False
.... ..0. .... .... = PTP_TWO_STEP: False
.... ...0 .... .... = PTP_ALTERNATE_MASTER: False
.... .... ..1. .... = FREQUENCY_TRACEABLE: True
.... .... ...1 .... = TIME_TRACEABLE: True
.... .... .... 1... = PTP_TIMESCALE: True
.... .... .... .1.. = PTP_UTC_REASONABLE: True
.... .... .... ..0. = PTP_LI_59: False
.... .... .... ...0 = PTP_LI_61: False
correction: 0.000000 nanoseconds
ClockIdentity: 0x7cfe90fffexxxxxx
SourcePortID: 50
sequenceId: 14229
control: Other Message (5)
logMessagePeriod: 1
originTimestamp (seconds): 1503285800
originTimestamp (nanoseconds): 768332414
originCurrentUTCOffset: 0
priority1: 128
grandmasterClockClass: 6
grandmasterClockAccuracy: The time is accurate to within 25 ns (0x20)
grandmasterClockVariance: 0
priority2: 128
grandmasterClockIdentity: 0x7cfe90fffexxxxxx
localStepsRemoved: 0
TimeSource: GPS (0x20)
Which results in the local ptp4l instance interpreting it as:
"GRANDMASTER_SETTINGS_NP" : {
"clockClass" : "255",
"clockAccuracy" : "0xfe",
"offsetScaledLogVariance" : "0xffff",
"currentUtcOffset" : "36",
"leap61" : "0",
"leap59" : "0",
"currentUtcOffsetValid" : "0",
"ptpTimescale" : "1",
"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?
We also have local clock:
"TIME_PROPERTIES_DATA_SET" : {
"currentUtcOffset" : "0",
"leap61" : "0",
"leap59" : "0",
"currentUtcOffsetValid" : "1",
"ptpTimescale" : "1",
"timeTraceable" : "1",
"frequencyTraceable" : "1",
"timeSource" : "0x20"
},
And I understand it is this timepropertiesDS.currentUTC which is compared
to current-utc-offset causing the warning.
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.
I'm told other clients (sfptpd and ptpd2) seem to take this ok, presumably
because they are simply calculating UTC by applying a zero offset which
happens to be correct.
Ptp4l also seems to be working ok, other than logging about temporal
vortices.
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?).
In this actual world however, the master may not be configurable whether
due to political/administrative reasons or simply because the appliance
doesn't expose the required details of it's master implementation.
Given ptp4l 1.8, is there any way we can allow folks to lessen noise in the
logs?
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.
Is this check performed only on BMC selection? 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.
I'd be grateful for any feedback or advice.
Thanks,
David
------------------------------------------------------------------------------
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
