Re: [Linuxptp-users] UTC Offset on grandmaster?

[Richard C. <ric...@gm...>]

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