Re: [Linuxptp-users] UTC Offset on grandmaster?
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
Re: [Linuxptp-users] UTC Offset on grandmaster?
|
From: Scott S. <ssi...@si...> - 2015-09-18 19:04:59
|
My GM (running ptp4l) is currently using NTP to set the system clock. I'm
not sure how to get NTP to give me a "correct" TAI offset (which I could
supply to PMC, for phc2sys to use).
My slaves *are* running ptp4l (and phc2sys). The only devices not using
ptp4l are the Cisco boundary clocks.
Here's a simplified diagram of what it looks like:
Boundary Clock 2 <>
Boundary Clock 3 <> Slaves 2
Grandmaster <> Boundary Clock 1 <>
Slaves 1
GM (ptp4l) has 35 / invalid
BC1 (Cisco) has 35 / invalid
BC2/3 (Cisco) have 36 / valid
Slaves (ptp4l) have 36 / valid
*Grandmaster: (39:7c)*
sending: GET PARENT_DATA_SET
0cc47a.fffe.63397c-0 seq 0 RESPONSE MANAGMENT PARENT_DATA_SET
parentPortIdentity 0cc47a.fffe.63397c-0
parentStats 0
observedParentOffsetScaledLogVariance 0xffff
observedParentClockPhaseChangeRate 0x7fffffff
grandmasterPriority1 125
gm.ClockClass 248
gm.ClockAccuracy 0xfe
gm.OffsetScaledLogVariance 0xffff
grandmasterPriority2 128
grandmasterIdentity 0cc47a.fffe.63397c
*Boundary Clock 1: (c7:81)*
PTP CLOCK TIME PROPERTY:
Current UTC Offset valid: 0
Current UTC Offset: 35
Leap59: 0
Leap61: 0
Time Traceable: 0
Frequency Traceable: 0
PTP Timescale: 1
Time Source: 0xa0(Internal Oscillator)
PTP PARENT PROPERTIES
Parent Clock:
Parent Clock Identity: 0c:c4:7a:ff:fe:63:39:7c
Parent Port Number: 1
Observed Parent Offset (log variance): N/A
Observed Parent Clock Phase Change Rate: N/A
Grandmaster Clock:
Grandmaster Clock Identity: 0c:c4:7a:ff:fe:63:39:7c
Grandmaster Clock Quality:
Class: 248
Accuracy: 254
Offset (log variance): 65535
Priority1: 125
Priority2: 128
*Boundary Clock 2: *
PTP CLOCK TIME PROPERTY:
Current UTC Offset valid: 1
Current UTC Offset: 36
Leap59: 0
Leap61: 0
Time Traceable: 0
Frequency Traceable: 0
PTP Timescale: 1
Time Source: 0xa0(Internal Oscillator)
PTP PARENT PROPERTIES
Parent Clock:
Parent Clock Identity: 74:a0:2f:ff:fe:93:c7:81
Parent Port Number: 47
Observed Parent Offset (log variance): N/A
Observed Parent Clock Phase Change Rate: N/A
Grandmaster Clock:
Grandmaster Clock Identity: 0c:c4:7a:ff:fe:63:39:7c
Grandmaster Clock Quality:
Class: 248
Accuracy: 254
Offset (log variance): 65535
Priority1: 125
Priority2: 128
*Slaves 1 (example):*
sending: GET PARENT_DATA_SET
0cc47a.fffe.3a2c5c-0 seq 0 RESPONSE MANAGMENT PARENT_DATA_SET
parentPortIdentity 74a02f.fffe.93c781-19
parentStats 0
observedParentOffsetScaledLogVariance 0xffff
observedParentClockPhaseChangeRate 0x7fffffff
grandmasterPriority1 125
gm.ClockClass 248
gm.ClockAccuracy 0xfe
gm.OffsetScaledLogVariance 0xffff
grandmasterPriority2 128
grandmasterIdentity 0cc47a.fffe.63397c
*Slaves 2 (example):*
sending: GET PARENT_DATA_SET
002590.fffe.138b0a-0 seq 0 RESPONSE MANAGMENT PARENT_DATA_SET
parentPortIdentity 88f031.fffe.a46bfc-4
parentStats 0
observedParentOffsetScaledLogVariance 0xffff
observedParentClockPhaseChangeRate 0x7fffffff
grandmasterPriority1 125
gm.ClockClass 248
gm.ClockAccuracy 0xfe
gm.OffsetScaledLogVariance 0xffff
grandmasterPriority2 128
grandmasterIdentity 0cc47a.fffe.63397c
Thanks,
Scott Silverman
On Fri, Sep 18, 2015 at 1:36 PM, Richard Cochran <ric...@gm...>
wrote:
> On Fri, Sep 18, 2015 at 04:16:40PM +0000, Keller, Jacob E wrote:
> > On Fri, 2015-09-18 at 11:11 -0500, Scott Silverman wrote:
> > > The offset option is documented, but maybe that is out of date?
>
> The -O is still valid, but it only for the situation where phc2sys
> cannot find out the TAI offset automatically, or for when you want to
> set it by hand.
>
> > > Should all of my slaves be picking up the UTC offset from the
> > > grandmaster? Because none of my slaves report an offset of 35, they
> > > all report offsets of 36 (in fact, the only other device reporting a
> > > 35 offset is the first boundary clock hop from the grandmaster, a
> > > Cisco switch). I'm not clear on how my other slaves (and other
> > > boundary clocks) are getting their (correct) offsets of 36.
> > >
> >
> > Yes, they should pick up the UTC from the grandmaster. I bet your
> > boundary clock is separating two networks which one has 35, and the
> > other has 36...
>
> I assume that your slaves are *not* running ptp4l, correct?
>
> Your ptp4l GM is doing the right thing. It provides an obsolete
> currentUtcOffset value, but it also sets currentUtcOffsetValid to
> "false", meaning "I don't know the correct value."
>
> Note that there is no configuration or command line option for
> currentUtcOffset by design, because this can only be correctly
> reported when your GM has a "live" connection to the outside world,
> like via GPS or NTP. If you do have the real time status available,
> then you change ptp4l on the fly using the management message that
> Jake mentioned.
>
> So the real question is, who is injecting the currentUtcOffset==36 and
> currentUtcOffsetValid==1, and how do they know the valid offset? The
> protocol says that the BC and slaves must honor what the GM tells
> them. They are supposed to take the information from the announce
> messages.
>
> Can you show us the responses from all the nodes from the
> PARENT_DATA_SET query?
>
> Thanks,
> Richard
>
--
DISCLAIMER: NOTICE REGARDING PRIVACY AND CONFIDENTIALITY
The information contained in and/or accompanying this communication is
intended only for use by the addressee(s) named herein and may contain
legally privileged and/or confidential information. If you are not the
intended recipient of this e-mail, you are hereby notified that any
dissemination, distribution or copying of this information, and any
attachments thereto, is strictly prohibited. If you have received this
e-mail in error, please immediately notify the sender and permanently
delete the original and any copy of any e-mail and any printout thereof.
Electronic transmissions cannot be guaranteed to be secure or error-free.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. Simplex Trading, LLC and its affiliates reserves the right to
intercept, monitor, and retain electronic communications to and from its
system as permitted by law. Simplex Trading, LLC is a registered Broker
Dealer with CBOE and a Member of SIPC.
|
