On Thu, Jun 29, 2017 at 10:17:35AM +0200, Richard Cochran wrote:
> Looking at ptp4l, sending an incorrect currentUtcOffset with
> currentUtcOffsetValid=0 is technically not wrong, but I agree that we
> should retain the correct offset when provided by a GM, even after
> that GM disappears.
Over on
On Thu, Jul 20, 2017 at 01:09:24PM +0200, Petr Kulhavy wrote:
> Now the situation has changed. The master is in sync with the
> SW-timestamping slave and the HW-timestamping slave is 37 seconds behind.
> Why is that?
I guess because your PHC on the GM is set to UTC and not TAI.
Normally, when imp
Hi Richard,
thank you for the hints. I have loaded the same version of linuxptp on
all three devices and applied your configuration changes.
Now the situation has changed. The master is in sync with the
SW-timestamping slave and the HW-timestamping slave is 37 seconds behind.
Why is that?
Bel
On Tue, Jul 18, 2017 at 04:09:57PM +0200, Petr Kulhavy wrote:
> 1. GM using HW time stamping
Okay, so make sure the master has the correct UTC offset.
[global]
utc_offset 37
or
ptp4l --utc_offset=37
> The HW-timestamping slave is also running:
> /usr/sbin/phc2sys -s
Hi Richard,
The setup is as you say, with the difference that the GM is already
using HW time stamping:
1. GM using HW time stamping
2. Slave 1 using SW time stamping
3. Slave 2 using HW time stamping
So to recap, the two devices with HW timestamping (GM and slave 2) are
in sync, whereas the
On Fri, Jul 14, 2017 at 11:20:44AM +0200, Petr Kulhavy wrote:
> My master is another ptp4l running device. What you're saying would then
> mean that ptp4l in master mode sends its time in UTC.
So your setup is this?
1. GM using SW time stamping
2. Slave 1 using SW time stamping
3. Slave 2 using H
d PTP time unless it has a valid GPS lock) the problem went
away.
Cheers,
Gethyn
-Original Message-
From: Miroslav Lichvar [mailto:mlich...@redhat.com]
Sent: 14 July 2017 08:05
To: Petr Kulhavy
Cc: linuxptp-users@lists.sourceforge.net
Subject: Re: [Linuxptp-users] UTC offset
On Fri, J
uxptp-users] UTC offset
On Fri, Jul 14, 2017 at 12:32:58AM +0200, Petr Kulhavy wrote:
> I have two devices running linuxptp as slaves with the same
> configuration, the only difference is that one uses SW timestamping
> and the other HW timestamping.
> Both report the sa
On Fri, Jul 14, 2017 at 12:32:58AM +0200, Petr Kulhavy wrote:
> I have two devices running linuxptp as slaves with the same configuration,
> the only difference is that one uses SW timestamping and the other HW
> timestamping.
> Both report the same GM in `pmc GET TIME_STATUS_NP`, but they have a
>
On Wed, Jun 28, 2017 at 11:08:04PM +0200, Boris Boucher wrote:
> No, the CLIENTS are running ptpd.
Ok, then ptpd has a bug. It ignores the currentUtcOffsetValid member
of the TIME_PROPERTIES data set. You will need to fix that in order
to solve your start up problem, or you could instead work ar
2017-06-28 11:33 GMT+02:00 Richard Cochran :
>
> On Wed, Jun 21, 2017 at 07:57:21PM +0200, Boris Boucher wrote:
> > This change propagate to the CLIENTS and also to the system clock of the
> > SERVER via phc2sys.
> > And during 1 or 2 minutes, the system clock of the SERVER and the CLIENTS
> > are
On Wed, Jun 21, 2017 at 07:57:21PM +0200, Boris Boucher wrote:
> This change propagate to the CLIENTS and also to the system clock of the
> SERVER via phc2sys.
> And during 1 or 2 minutes, the system clock of the SERVER and the CLIENTS
> are not fully synchronized,
> causing the system to fail to p
I don't know if it's the recommended solution, but I encountered a similar
problem a while back. My solution was to use pmc as follows:
# pmc -u -b 0 'set GRANDMASTER_SETTINGS_NP clockClass 248 clockAccuracy
0xfe offsetScaledLogVariance 0x currentUtcOffset 37 leap61 0 leap59 0
currentUtcOffset
On Wed, Jun 21, 2017 at 07:57:21PM +0200, Boris Boucher wrote:
> The problem is, if the grand master is lost (power failure, network
> issue), my boundary
> clock promotes itself as grand master, and uses its own knowledge of the
> UTC offset instead
> of the last known offset from the secure s
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
wrote:
> On Fri, Sep 1
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 currentUtcOffsetVali
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'
On Fri, Sep 18, 2015 at 04:16:40PM +, 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 automat
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 sourcefor
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 phc2
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 "currentUtcOf
21 matches
Mail list logo
