Thread: [Linuxptp-users] UTC Offset on grandmaster?
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: Scott S. <ssi...@si...> - 2015-09-18 14:32:54
|
I recently ran into an issue where slaves were all off by exactly one second. I believe that the UTC offset was the source of this issue. Running linuxptp as grandmaster, the "currentUtcOffset" is reported as 35, and "currentUtcOffsetValid" is reported as 0: # pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET' sending: GET TIME_PROPERTIES_DATA_SET 0cc47a.fffe.63397c-0 seq 0 RESPONSE MANAGMENT TIME_PROPERTIES_DATA_SET currentUtcOffset 35 leap61 0 leap59 0 currentUtcOffsetValid 0 ptpTimescale 1 timeTraceable 0 frequencyTraceable 0 timeSource 0xa0 It is my understanding that the current UTC/TAI offset is 36. In fact, slaves (behind boundary clocks) report a UTC/TAI offset of 36: Here is the output from one slave (behind a single boundary clock): # pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET' sending: GET TIME_PROPERTIES_DATA_SET 0cc47a.fffe.3a2c5c-0 seq 0 RESPONSE MANAGMENT TIME_PROPERTIES_DATA_SET currentUtcOffset 36 leap61 0 leap59 0 currentUtcOffsetValid 1 ptpTimescale 1 timeTraceable 0 frequencyTraceable 0 timeSource 0xa0 I'm running linuxptp (1.5) on CentOS6 (kernel 4.0.4). I am running phc2sys with the following configuration: -s CLOCK_REALTIME -c eth0 I am running ptp4l with the following configuration: -i eth0 -f /etc/ptp4l.conf My ptp4l.conf is the package default, with the exception of the priority1 (set to 125). I tried adding a "-O 36" to the phc2sys command line, but it had no effect on the reported UTC offset. Thanks, Scott Silverman -- 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. |
|
From: Keller, J. E <jac...@in...> - 2015-09-18 16:06:24
|
On Fri, 2015-09-18 at 09:01 -0500, Scott Silverman wrote: > I recently ran into an issue where slaves were all off by exactly one > second. I believe that the UTC offset was the source of this issue. > > Running linuxptp as grandmaster, the "currentUtcOffset" is reported > as 35, and "currentUtcOffsetValid" is reported as 0: > > # pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET' > sending: GET TIME_PROPERTIES_DATA_SET > 0cc47a.fffe.63397c-0 seq 0 RESPONSE MANAGMENT > TIME_PROPERTIES_DATA_SET > currentUtcOffset 35 > leap61 0 > leap59 0 > currentUtcOffsetValid 0 > ptpTimescale 1 > timeTraceable 0 > frequencyTraceable 0 > timeSource 0xa0 > > It is my understanding that the current UTC/TAI offset is 36. In > fact, slaves (behind boundary clocks) report a UTC/TAI offset of 36: > Yes is is. There was just a patch to fix this sent to the mailing list. You should be able to correct this via a management message though using pmc.. use the GRANDMASTER_SETTINGS_NP, which is a non portable extension of the management protocol for PTP, you can reset the UTC offset to 36. > Here is the output from one slave (behind a single boundary clock): > # pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET' > sending: GET TIME_PROPERTIES_DATA_SET > 0cc47a.fffe.3a2c5c-0 seq 0 RESPONSE MANAGMENT > TIME_PROPERTIES_DATA_SET > currentUtcOffset 36 > leap61 0 > leap59 0 > currentUtcOffsetValid 1 > ptpTimescale 1 > timeTraceable 0 > frequencyTraceable 0 > timeSource 0xa0 > > > > I'm running linuxptp (1.5) on CentOS6 (kernel 4.0.4). > > I am running phc2sys with the following configuration: > -s CLOCK_REALTIME -c eth0 > > I am running ptp4l with the following configuration: > -i eth0 -f /etc/ptp4l.conf > > My ptp4l.conf is the package default, with the exception of the > priority1 (set to 125). > > I tried adding a "-O 36" to the phc2sys command line, but it had no > effect on the reported UTC offset. > > That isn't the correct option. I don't believe there is an actual option here, but you should be able to use pmc to set this. It might be worth adding a configuration option as well? Regards, Jake > > > > Thanks, > > Scott Silverman |
|
From: Scott S. <ssi...@si...> - 2015-09-18 16:12:03
|
Thanks for the prompt response.
As for the patch sent to the mailing list, I just joined, and the
sourceforge archives are broken (a sourceforge 403 error is returned), so I
couldn't look back.
The offset option is documented, but maybe that is out of date?
The documentation (man page) for phc2sys lists the following:
-O offset
Specify the offset between the slave and master times in
seconds. Not compatible with
the -a option. See TIME SCALE USAGE below.
And then, in TIME SCALE USAGE:
Phc2sys acquires the offset value either by reading it from ptp4l when -a
or -w is in effect
or from command line when -O is supplied. Failure to maintain the
correct offset can result
in local system clock being off some seconds to domain master system
clock when in slave
mode, or incorect PTP time announced to the network in case the host
is the domain master.
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.
Thanks,
Scott Silverman
On Fri, Sep 18, 2015 at 11:05 AM, Keller, Jacob E <jac...@in...>
wrote:
> On Fri, 2015-09-18 at 09:01 -0500, Scott Silverman wrote:
> > I recently ran into an issue where slaves were all off by exactly one
> > second. I believe that the UTC offset was the source of this issue.
> >
> > Running linuxptp as grandmaster, the "currentUtcOffset" is reported
> > as 35, and "currentUtcOffsetValid" is reported as 0:
> >
> > # pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET'
> > sending: GET TIME_PROPERTIES_DATA_SET
> > 0cc47a.fffe.63397c-0 seq 0 RESPONSE MANAGMENT
> > TIME_PROPERTIES_DATA_SET
> > currentUtcOffset 35
> > leap61 0
> > leap59 0
> > currentUtcOffsetValid 0
> > ptpTimescale 1
> > timeTraceable 0
> > frequencyTraceable 0
> > timeSource 0xa0
> >
> > It is my understanding that the current UTC/TAI offset is 36. In
> > fact, slaves (behind boundary clocks) report a UTC/TAI offset of 36:
> >
>
> Yes is is. There was just a patch to fix this sent to the mailing list.
> You should be able to correct this via a management message though
> using pmc.. use the GRANDMASTER_SETTINGS_NP, which is a non portable
> extension of the management protocol for PTP, you can reset the UTC
> offset to 36.
>
> > Here is the output from one slave (behind a single boundary clock):
> > # pmc -u -b 0 'get TIME_PROPERTIES_DATA_SET'
> > sending: GET TIME_PROPERTIES_DATA_SET
> > 0cc47a.fffe.3a2c5c-0 seq 0 RESPONSE MANAGMENT
> > TIME_PROPERTIES_DATA_SET
> > currentUtcOffset 36
> > leap61 0
> > leap59 0
> > currentUtcOffsetValid 1
> > ptpTimescale 1
> > timeTraceable 0
> > frequencyTraceable 0
> > timeSource 0xa0
> >
> >
> >
> > I'm running linuxptp (1.5) on CentOS6 (kernel 4.0.4).
> >
> > I am running phc2sys with the following configuration:
> > -s CLOCK_REALTIME -c eth0
> >
> > I am running ptp4l with the following configuration:
> > -i eth0 -f /etc/ptp4l.conf
> >
> > My ptp4l.conf is the package default, with the exception of the
> > priority1 (set to 125).
> >
> > I tried adding a "-O 36" to the phc2sys command line, but it had no
> > effect on the reported UTC offset.
> >
> >
>
> That isn't the correct option. I don't believe there is an actual
> option here, but you should be able to use pmc to set this. It might be
> worth adding a configuration option as well?
>
> Regards,
> Jake
>
> >
> >
> >
> > Thanks,
> >
> > Scott Silverman
>
--
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.
|
|
From: Keller, J. E <jac...@in...> - 2015-09-18 16:16:53
|
On Fri, 2015-09-18 at 11:11 -0500, Scott Silverman wrote: > Thanks for the prompt response. > > As for the patch sent to the mailing list, I just joined, and the > sourceforge archives are broken (a sourceforge 403 error is > returned), so I couldn't look back. > Try gmane instead. The sourceforge achives are really bad. http://news.gmane.org/gmane.comp.linux.ptp.devel > > The offset option is documented, but maybe that is out of date? > > The documentation (man page) for phc2sys lists the following: > -O offset > Specify the offset between the slave and master times > in seconds. Not compatible with > the -a option. See TIME SCALE USAGE below. > Yes, but this is not the UTC offset. This is a separate option for a different type of correction, and what is actually happening here is the two clocks end up in "sync" but report differently because it reports UTC time, not the TAI timescale used by PTP, thus the 1 second offset. > And then, in TIME SCALE USAGE: > Phc2sys acquires the offset value either by reading it from ptp4l > when -a or -w is in effect > or from command line when -O is supplied. Failure to maintain > the correct offset can result > in local system clock being off some seconds to domain master > system clock when in slave > mode, or incorect PTP time announced to the network in case > the host is the domain master. > > 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... Regards, Jake |
|
From: Richard C. <ric...@gm...> - 2015-09-18 18:36:24
|
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 |
|
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.
|
|
From: Richard C. <ric...@gm...> - 2015-09-18 19:09:08
|
On Fri, Sep 18, 2015 at 01:58:09PM -0500, Scott Silverman wrote: > My slaves *are* running ptp4l (and phc2sys). The only devices not using > ptp4l are the Cisco boundary clocks. All the nodes report the same grandmasterIdentity. I guess that one of your BCs is introducing the currentUtcOffsetValid flag, as Jake said. You can sniff the announce messages between BC1 and BC2 to find out who is at fault. Maybe the BCs are also NTP cleints and therefore feel that they know the correct offset? Thanks, Richard |
|
From: Scott S. <ssi...@si...> - 2015-10-02 14:10:56
|
Cisco has confirmed a bug in their PTP implementation (CSCuw44058, requires login). It causes their boundary clock to ignore the received offset and just use whatever it wants (in this case, 36). Thanks, Scott Silverman On Fri, Sep 18, 2015 at 2:08 PM, Richard Cochran <ric...@gm...> wrote: > On Fri, Sep 18, 2015 at 01:58:09PM -0500, Scott Silverman wrote: > > My slaves *are* running ptp4l (and phc2sys). The only devices not using > > ptp4l are the Cisco boundary clocks. > > All the nodes report the same grandmasterIdentity. I guess that one > of your BCs is introducing the currentUtcOffsetValid flag, as Jake > said. You can sniff the announce messages between BC1 and BC2 to find > out who is at fault. > > Maybe the BCs are also NTP cleints and therefore feel that they know > the correct offset? > > 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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X