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

[Scott S. <ssi...@si...>]

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.