linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] software timestamp mode

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

On Wed, Nov 04, 2015 at 08:29:06AM +0100, frank wrote:
> Do I need to change more configuration settings? Or is this the wrong
> way to do things?

The choices are:

1. HW time stamping with PHC
2. SW time stamping with the system clock (CLOCK_REALTIME)

You cannot mix the two.  So, for SW time stamping, leave off the '-p'
command line flag.

Thanks,
Richard

[Linuxptp-users] software timestamp mode

[frank <sou...@gm...>]

Hi,

I would like to use linuxptp in a project using hardware timestamp mode.
The project accesses the ptp time by calling clock_gettime with a
clock_id derived from /dev/ptp0.

However my automatic regression system host(jenkins) does not support
this mode.
So I modified the ptp4l.conf file to use
..
time_stamping software
..

There seems to be ptp activity and the host even seems to become master
for the ptp system,
but I cannot get the ptp time as /dev/ptp0 does not exist.

Do I need to change more configuration settings? Or is this the wrong
way to do things?

kind regards
  Frank

Re: [Linuxptp-users] LinuxPTP on i.mx6 Freescale

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

On Thu, Oct 29, 2015 at 09:20:02AM +0100, Michael Kasprowicz wrote:
> Good morning everyone,
> 
> I have trouble getting ptp4l to work on Freescale i.mx6 with 'fec'
> supported MAC as a slave.

I have never tested the imx6 myself, and I have my doubts about the
driver...

> In one failed case my PHY is BCM54610  -> with the following logs:

But it is strange that the PHY should make any difference.

> SLAVE-end
> root@gatebox3:~# ptp4l -H -m -s -i eth0
> ptp4l[5870.765]: selected /dev/ptp0 as PTP clock
> ptp4l[5870.768]: driver changed our HWTSTAMP options
> ptp4l[5870.769]: tx_type 1 not 1
> ptp4l[5870.769]: rx_filter 1 not 12
> ptp4l[5870.770]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[5870.771]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[5872.686]: port 1: new foreign master 00e04b.fffe.51f245-1
> ptp4l[5876.686]: selected best master clock 00e04b.fffe.51f245
> ptp4l[5876.686]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[5878.686]: master offset 3188991333 s0 freq +0 path delay 0
...
> ptp4l[5884.687]: master offset 3188991333 s0 freq +0 path delay 0

It looks like no path delay packets are getting through.  Can you
confirm this with wireshark?

Also, does the "s0" field ever change to s1 or s2?
 
> In another successful case the pHY is Micrel KSZ9021 RL/RN ->
> SLAVE-end
> root@sabrelite:~# ptp4l -H -m -i eth0 -s
> ptp4l[664.648]: selected /dev/ptp0 as PTP clock
> ptp4l[664.651]: driver changed our HWTSTAMP options
> ptp4l[664.651]: tx_type 1 not 1
> ptp4l[664.651]: rx_filter 1 not 12
> ptp4l[664.652]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[664.652]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[665.722]: port 1: new foreign master 00e04b.fffe.51f245-1
> ptp4l[669.722]: selected best master clock 00e04b.fffe.51f245
> ptp4l[669.723]: foreign master not using PTP timescale
> ptp4l[669.724]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[670.723]: master offset -80203908175625 s0 freq +32767998 path delay
> 11507904
> ptp4l[671.723]: master offset -80203940546562 s1 freq +450418 path delay
> 12655417
> ptp4l[673.723]: master offset 5921778 s2 freq +6372196 path delay 5867958
> ptp4l[673.724]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
> ptp4l[674.723]: master offset 2965854 s2 freq +5192805 path delay 2606170
> ptp4l[675.723]: master offset -1009254 s2 freq +2107453 path delay 1606252
> ptp4l[676.723]: master offset -2829995 s2 freq -16064 path delay 1369544
> ptp4l[677.724]: master offset -2549452 s2 freq -584520 path delay 1132836
> ptp4l[678.724]: master offset -1687593 s2 freq -487496 path delay 882099
> ptp4l[679.724]: master offset -720246 s2 freq -26427 path delay 429687
> ptp4l[680.724]: master offset -262821 s2 freq +214924 path delay 27603
> ptp4l[681.724]: master offset -449180 s2 freq -50281 path delay 27603
> ptp4l[682.724]: master offset -360700 s2 freq -96555 path delay 17556
> ptp4l[683.724]: master offset -224643 s2 freq -68708 path delay 7019

This is not very close.  Does the synchronization converge to under 1 usec?
 
Thanks,
Richard

[Linuxptp-users] LinuxPTP on i.mx6 Freescale

[Michael K. <boo...@gm...>]

Good morning everyone,

I have trouble getting ptp4l to work on Freescale i.mx6 with 'fec'
supported MAC as a slave.
In one failed case my PHY is BCM54610  -> with the following logs:

SLAVE-end
root@gatebox3:~# ptp4l -H -m -s -i eth0
ptp4l[5870.765]: selected /dev/ptp0 as PTP clock
ptp4l[5870.768]: driver changed our HWTSTAMP options
ptp4l[5870.769]: tx_type 1 not 1
ptp4l[5870.769]: rx_filter 1 not 12
ptp4l[5870.770]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[5870.771]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[5872.686]: port 1: new foreign master 00e04b.fffe.51f245-1
ptp4l[5876.686]: selected best master clock 00e04b.fffe.51f245
ptp4l[5876.686]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[5878.686]: master offset 3188991333 s0 freq +0 path delay 0
ptp4l[5879.686]: master offset 3188991333 s0 freq +0 path delay 0
ptp4l[5880.686]: master offset 3188991333 s0 freq +0 path delay 0
ptp4l[5881.686]: master offset 3188991333 s0 freq +0 path delay 0
ptp4l[5882.687]: master offset 3188991333 s0 freq +0 path delay 0
ptp4l[5883.687]: master offset 3188991333 s0 freq +0 path delay 0
ptp4l[5884.687]: master offset 3188991333 s0 freq +0 path delay 0

In another successful case the pHY is Micrel KSZ9021 RL/RN ->
SLAVE-end
root@sabrelite:~# ptp4l -H -m -i eth0 -s
ptp4l[664.648]: selected /dev/ptp0 as PTP clock
ptp4l[664.651]: driver changed our HWTSTAMP options
ptp4l[664.651]: tx_type 1 not 1
ptp4l[664.651]: rx_filter 1 not 12
ptp4l[664.652]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[664.652]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[665.722]: port 1: new foreign master 00e04b.fffe.51f245-1
ptp4l[669.722]: selected best master clock 00e04b.fffe.51f245
ptp4l[669.723]: foreign master not using PTP timescale
ptp4l[669.724]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[670.723]: master offset -80203908175625 s0 freq +32767998 path delay
11507904
ptp4l[671.723]: master offset -80203940546562 s1 freq +450418 path delay
12655417
ptp4l[673.723]: master offset 5921778 s2 freq +6372196 path delay 5867958
ptp4l[673.724]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[674.723]: master offset 2965854 s2 freq +5192805 path delay 2606170
ptp4l[675.723]: master offset -1009254 s2 freq +2107453 path delay 1606252
ptp4l[676.723]: master offset -2829995 s2 freq -16064 path delay 1369544
ptp4l[677.724]: master offset -2549452 s2 freq -584520 path delay 1132836
ptp4l[678.724]: master offset -1687593 s2 freq -487496 path delay 882099
ptp4l[679.724]: master offset -720246 s2 freq -26427 path delay 429687
ptp4l[680.724]: master offset -262821 s2 freq +214924 path delay 27603
ptp4l[681.724]: master offset -449180 s2 freq -50281 path delay 27603
ptp4l[682.724]: master offset -360700 s2 freq -96555 path delay 17556
ptp4l[683.724]: master offset -224643 s2 freq -68708 path delay 7019

The Linux kernel in use is 3.14.28 with the following parameters:
CONFIG_NETWORK_PHY_TIMESTAMPING=y
CONFIG_PPS=y
CONFIG_PTP_1588_CLOCK=y

Any hints / suggestions I will really appreciate.

best regards
Kasp

Re: [Linuxptp-users] Testing for PTP over SyncE

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

On Wed, Oct 28, 2015 at 08:58:21AM +0100, Xavier Bestel wrote:
> Le vendredi 23 octobre 2015 à 19:02 +0200, Xavier Bestel a écrit :
> > Hi guys,
> > 
> > I know some of you have tested for this setup (PTP over a synchronous
> > ethernet link).
> > What do you guys use for this ? I'm particularly looking for a cheap
> > slave and a switch which could work in this setup.
> 
> So no one does this except Richard ?

Outside of one project, I have never seen real life SyncE systems.
I guess that SyncE is mostly deployed in telecom, with propriety SW.

I don't think there is any cheap HW for SyncE.  For the switch, you
can consider the Marvell Link Street SOHO line.  If your links are
gigbit and you configure the Marvell, then any gigbit client will
accept the Marvell's master clock.  At least, I think that is how it
is supposed to work...

Good luck,
Richard

Re: [Linuxptp-users] Testing for PTP over SyncE

[Xavier B. <xav...@fr...>]

Le vendredi 23 octobre 2015 à 19:02 +0200, Xavier Bestel a écrit :
> Hi guys,
> 
> I know some of you have tested for this setup (PTP over a synchronous
> ethernet link).
> What do you guys use for this ? I'm particularly looking for a cheap
> slave and a switch which could work in this setup.

So no one does this except Richard ?

	Xav

[Linuxptp-users] Testing for PTP over SyncE

[Xavier B. <xav...@fr...>]

Hi guys,

I know some of you have tested for this setup (PTP over a synchronous
ethernet link).
What do you guys use for this ? I'm particularly looking for a cheap
slave and a switch which could work in this setup.

Regards,
	Xav

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

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

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.

Re: [Linuxptp-users] [Linuxptp-devel] [announce] version 1.6 released

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

On Tue, Sep 22, 2015 at 04:42:31PM +0000, Keller, Jacob E wrote:
> Thanks richard. I don't see the v1.6 tag..

Oops.  Sorry.  It should be there now.

Thanks,
Richard

Re: [Linuxptp-users] [Linuxptp-devel] [announce] version 1.6 released

[Keller, J. E <jac...@in...>]

On Sat, 2015-09-19 at 21:12 +0200, Richard Cochran wrote:
> Dear linuxptp users and developers,
> 
> Nine months since the previous release, I announce version 1.6 of
> linuxptp.  I pushed out tag v1.6 and released a tar ball on SF. 

Thanks richard. I don't see the v1.6 tag..

Regards,
Jake

[Linuxptp-users] [announce] version 1.6 released

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

Dear linuxptp users and developers,

Nine months since the previous release, I announce version 1.6 of
linuxptp.  I pushed out tag v1.6 and released a tar ball on SF. 

Thanks to the contributors, IOhannes, Libor, and Miroslav.  The short
log is appended, below.

Enjoy,
Richard


IOhannes m zmölnig (4):
      Explain how to contribute patches
      fixed spelling: "MANAGEMENT"
      fixed hyphen/minus signs in groff
      install into DESTDIR

Libor Pechacek (1):
      Update UTC offset

Miroslav Lichvar (16):
      timemaster: set mode in ntp config to create private SHM segments.
      phc2sys: don't synchronize clock to itself in automatic mode.
      Convert and correct time stamps early.
      Refactor time stamp processing.
      tsproc: add raw and weighting modes.
      servo: add support for weighted samples.
      linreg: use sample weight.
      pi: use sample weight.
      timemaster: kill processes by PID instead of process group.
      util: add wrappers for memory allocation functions.
      util: exit in string_* and parray_* functions when allocation fails.
      timemaster: use wrapped memory allocation functions.
      udp6: set hop limit with udp_ttl option.
      util: add function for simple rate limiting.
      print: add rate limited versions of pr_* macros.
      port: print bogus delay request message as rate limited info.

Richard Cochran (96):
      clock: support management SET of the priority attributes.
      pmc: support setting the priority attributes.
      Add a servo that inhibits all frequency adjustment
      Add a configuration option to use the "nullf" servo.
      clock: store the configuration in the clock data structure.
      clock: add a method to obtain the configuration.
      pmc: require a configuration for creating a PMC instance.
      transport: store the configuration in the transport data structure.
      Introduce a simple hash table implementation.
      config: Add a hash table into the data structure.
      config: introduce a new API for reading configuration settings.
      udp: configure the socket with the TTL option.
      config: convert the 'assume_two_step' option to the new scheme.
      config: convert 'tx_timestamp_timeout' to the new scheme.
      config: convert the 'check_fup_sync' option to the new scheme.
      servo: store the configuration in the servo data structure.
      config: add methods to set values taken from the command line.
      config: convert the 'step_threshold' option to the new scheme.
      config: convert the 'first_step_threshold' option to the new scheme.
      config: convert the 'max_frequency' option to the new scheme.
      config: convert 'logging_level' to the new scheme.
      config: convert 'use_syslog' to the new scheme.
      config: convert 'verbose' to the new scheme.
      config: convert 'pi_proportional_const' to the new scheme.
      config: convert 'pi_integral_const' to the new scheme.
      config: convert 'pi_proportional_scale' to the new scheme.
      config: convert 'pi_proportional_exponent' to the new scheme.
      config: convert 'pi_proportional_norm_max' to the new scheme.
      config: convert 'pi_integral_scale' to the new scheme.
      config: convert 'pi_integral_exponent' to the new scheme.
      config: convert 'pi_integral_norm_max' to the new scheme.
      config: convert 'ntpshm_segment' to the new scheme.
      config: port: convert 'delayAsymmetry' to the new scheme.
      config: port: convert 'logAnnounceInterval' to the new scheme.
      config: port: convert 'logSyncInterval' to the new scheme.
      config: port: convert 'logMinDelayReqInterval' to the new scheme.
      config: port: convert 'logMinPdelayReqInterval' to the new scheme.
      config: port: convert 'announceReceiptTimeout' to the new scheme.
      config: port: convert 'syncReceiptTimeout' to the new scheme.
      config: prot: convert 'transportSpecific' to the new scheme.
      port: change 'announce_span' into a macro.
      config: port: convert 'path_trace_enabled' to the new scheme.
      config: port: convert 'follow_up_info' to the new scheme.
      config: clock, port: convert 'freq_est_interval' to the new scheme.
      config: port: convert 'neighborPropDelayThresh' to new scheme.
      config: port: convert 'min_neighbor_prop_delay' to the new scheme.
      config: port: convert 'egressLatency' to the new scheme.
      config: port: convert 'ingressLatency' to the new scheme.
      config: port: convert 'delay_filter_length' to the new scheme.
      config: clock, port: convert 'boundary_clock_jbod' to the new scheme.
      config: convert 'free_running' to the new scheme.
      config: convert 'gmCapable' to the new scheme.
      config: convert 'summary_interval' to the new scheme.
      config: convert 'kernel_leap' to the new scheme.
      config: convert 'sanity_freq_limit' to the new scheme.
      config: convert 'timeSource' to the new scheme.
      config: convert the fault interval options to the new scheme.
      config: remove the 'port_defaults' structure.
      config: convert 'udp6_scope' to the new scheme.
      config: convert 'slaveOnly' and 'twoStepFlag' to the new scheme.
      config: convert 'priority1' and 'priority2' to the new scheme.
      config: convert 'clockClass' to the new scheme.
      config: convert 'clockAccuracy' to the new scheme.
      config: convert 'offsetScaledLogVariance' to the new scheme.
      config: convert 'domainNumber' to the new scheme.
      config: add support for enumerated types with string labels.
      config: convert 'network_transport' to the new scheme.
      config: convert 'delay_mechanism' to the new scheme.
      config: convert 'tsproc_mode' to the new scheme.
      config: convert 'delay_filter' to the new scheme.
      config: convert 'time_stamping' to the new scheme.
      config: convert 'clock_servo' to the new scheme.
      ptp4l: set print levels earlier.
      config: introduce a string type.
      util: add a helper function to scan a MAC address.
      config: convert 'ptp_dst_mac', letting it be a per-port option.
      config: convert 'p2p_dst_mac', letting it be a per-port option.
      config: convert 'uds_address' to the new scheme.
      util: provide the 'count_char' helper function.
      config: convert 'productDescription' to the new scheme.
      config: convert 'revisionData' to the new scheme.
      config: convert 'userDescription' to the new scheme.
      config: convert 'manufacturerIdentity' to the new scheme.
      config: remove the last remaining legacy item.
      config: save a block from falling off the RHS of the page.
      config: refactor the parsing code.
      config: introduce a proper creation method.
      Fix integer overflow in the foreign master bookkeeping code.
      port: constrain the master's logMinDelayReqInterval.
      udp: set the destination port unconditionally.
      udp6: set the destination port unconditionally.
      Use the standardized low level socket address format.
      Support hybrid E2E using unicast delay requests and responses.
      uds: restore delay mechanism to zero value.
      Merge the hybrid E2E work.
      Version 1.6

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

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

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

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

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

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.

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

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

[Keller, J. E <jac...@in...>]

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

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.

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

[Keller, J. E <jac...@in...>]

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

Re: [Linuxptp-users] system1: ptp4l master offset continues to climb: step_threshold 1

[Keller, J. E <jac...@in...>]

On Thu, 2015-09-17 at 16:04 -0400, Dale Smith wrote:
> Yes indeed!  I *was* going to mention that it was changing in the
> wrong direction, but somehow I sent the mail before I added that.
> 
> Yep  Looks like broken HW or driver.
> 
> -Dale

My gut reaction is an overflow in the frequency adjustment in the
driver, as this appears similar behavior to an issue we had on one of
the Intel drivers. If you were going to pursue this at the driver
level, I would start there.

Regards,
Jake

[Linuxptp-users] UTC Offset on grandmaster?

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

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.

Re: [Linuxptp-users] system1: ptp4l master offset continues to climb: step_threshold 1

[Dale S. <dal...@gm...>]

Yes indeed!  I *was* going to mention that it was changing in the wrong
direction, but somehow I sent the mail before I added that.

Yep  Looks like broken HW or driver.

-Dale

On Thu, Sep 17, 2015 at 2:18 PM, Richard Cochran <ric...@gm...>
wrote:

> On Thu, Sep 17, 2015 at 01:34:53PM -0400, Dale Smith wrote:
> > I could be wrong, but isn't the step_threshold in seconds?  And -106627
> is
> > about  106 microseconds.  So won't it take quite a while yet before the
> > threshold is reached?
>
> Yes, you are right.  The value is in seconds.  However, I assumed that
> Harold knew this, because I quoted the man page to him and setting the
> threshold to 1 nanosecond makes no sense at all.
>
> The real problem is the drifting away.  It is a sign of broken HW (or
> driver), and we don't have any configuration parameter to cure that!
>
> Thanks,
> Richard
>

Re: [Linuxptp-users] system1: ptp4l master offset continues to climb: step_threshold 1

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

On Thu, Sep 17, 2015 at 01:34:53PM -0400, Dale Smith wrote:
> I could be wrong, but isn't the step_threshold in seconds?  And -106627 is
> about  106 microseconds.  So won't it take quite a while yet before the
> threshold is reached?

Yes, you are right.  The value is in seconds.  However, I assumed that
Harold knew this, because I quoted the man page to him and setting the
threshold to 1 nanosecond makes no sense at all.

The real problem is the drifting away.  It is a sign of broken HW (or
driver), and we don't have any configuration parameter to cure that!

Thanks,
Richard

Re: [Linuxptp-users] system1: ptp4l master offset continues to climb: step_threshold 1

[Dale S. <dal...@gm...>]

I could be wrong, but isn't the step_threshold in seconds?  And -106627 is
about  106 microseconds.  So won't it take quite a while yet before the
threshold is reached?

-Dale

On Thu, Sep 17, 2015 at 11:13 AM, Harold Lapprich <
hla...@pi...> wrote:

> To Whom It May Concern,
>
>
>
> Have a multi-system configuration and on one of the systems 'ptp4l master
> offset' continues to climb with 'step_theshold 1', might there be some
> other configuration parameter I am over-looking ?
>
>
>
> Thanks,
>
> Harold
>
>
>
> system:
>
>
>
>                ptp4l.conf:
>
>
>
>                               root@zx3-pm3-zynq7:~# cat
> /usr/bin/ptp4l.conf
>
>                               [global]
>
>                               verbose 1
>
>                               step_threshold 1
>
>                               use_syslog 0
>
>                               [eth0]
>
>
>
>
>
>                ptp4l:
>
>
>
>                               root@zx3-pm3-zynq7:~# /usr/bin/ptp4l -f
> /usr/bin/ptp4l.conf &
>
>
>
>                               ptp4l[4477.362]: port 1: INITIALIZING to
> LISTENING on INITIALIZE
>
>                               ptp4l[4477.363]: port 0: INITIALIZING to
> LISTENING on INITIALIZE
>
>                               ptp4l[4478.668]: port 1: new foreign master
> 000a35.fffe.01225c-1
>
>                               ptp4l[4482.668]: selected best master clock
> 000a35.fffe.01225c
>
>                               ptp4l[4482.668]: port 1: LISTENING to
> UNCALIBRATED on RS_SLAVE
>
>                               ptp4l[4484.392]: master offset   -2756145 s0
> freq -3910000 path delay     30485
>
>                               ptp4l[4485.393]: master offset   -2767595 s1
> freq -3910000 path delay     30485
>
>                               ptp4l[4486.393]: master offset     -11892 s2
> freq -3910000 path delay     30485
>
>                               ptp4l[4486.393]: port 1: UNCALIBRATED to
> SLAVE on MASTER_CLOCK_SELECTED
>
>                               ptp4l[4487.393]: master offset     -23642 s2
> freq -3910000 path delay     30485
>
>                               ptp4l[4488.393]: master offset     -34899 s2
> freq -3910000 path delay     30485
>
>                               ptp4l[4489.393]: master offset     -47149 s2
> freq -3910000 path delay     30485
>
>                               ptp4l[4490.393]: master offset     -57433 s2
> freq -3910000 path delay     29612
>
>                               ptp4l[4491.394]: master offset     -69590 s2
> freq -3910000 path delay     29368
>
>                               ptp4l[4492.394]: master offset     -81961 s2
> freq -3910000 path delay     29612
>
>                               ptp4l[4493.394]: master offset     -93790 s2
> freq -3910000 path delay     29612
>
>                               ptp4l[4494.394]: master offset    -106627 s2
> freq -3910000 path delay     29368
>
>
>
>
>
>
>
>                phc2sys:
>
>
>
>                               phc2sys[4598.771]: port 00214a.fffe.000003-1
> changed state
>
>                               phc2sys[4598.772]: reconfiguring after port
> state change
>
>                               phc2sys[4598.773]: selecting CLOCK_REALTIME
> for synchronization
>
>                               phc2sys[4598.773]: selecting eth0 as the
> master clock
>
>                               phc2sys[4598.773]: phc offset -10536165 s0
> freq   +3833 delay   2814
>
>                               phc2sys[4599.774]: phc offset -10517174 s1
> freq  +22810 delay   2838
>
>                               phc2sys[4600.774]: phc offset    -22424 s2
> freq    +386 delay   2769
>
>                               phc2sys[4601.775]: phc offset    -22820 s2
> freq   -6737 delay   2841
>
>                               phc2sys[4602.775]: phc offset    -16038 s2
> freq   -6801 delay   2787
>
>                               phc2sys[4603.775]: phc offset     -9142 s2
> freq   -4717 delay   2829
>
>                               phc2sys[4604.776]: phc offset     -4444 s2
> freq   -2761 delay   2802
>
>                               phc2sys[4605.776]: phc offset     -1673 s2
> freq   -1324 delay   2817
>
>                               phc2sys[4606.777]: phc offset      -312 s2
> freq    -465 delay   2775
>
>                               phc2sys[4607.777]: phc offset       149 s2
> freq     -97 delay   2835
>
>                               phc2sys[4608.778]: phc offset       297 s2
> freq     +96 delay   2802
>
>                               phc2sys[4609.778]: phc offset       197 s2
> freq     +85 delay   2799
>
>                               phc2sys[4610.778]: phc offset       137 s2
> freq     +84 delay   2790
>
>                               phc2sys[4611.779]: phc offset        63 s2
> freq     +51 delay   2811
>
>                               phc2sys[4612.779]: phc offset        49 s2
> freq     +56 delay   2754
>
>                               phc2sys[4613.780]: phc offset       -20 s2
> freq      +1 delay   2814
>
>                               phc2sys[4614.780]: phc offset        35 s2
> freq     +50 delay   2787
>
>                               phc2sys[4615.441]: phc offset        -7 s2
> freq     +19 delay   2754
>
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>
>

Re: [Linuxptp-users] system1: ptp4l master offset continues to climb: step_threshold 1

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

On Thu, Sep 17, 2015 at 03:13:55PM +0000, Harold Lapprich wrote:
> ptp4l[4486.393]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
> ptp4l[4487.393]: master offset     -23642 s2 freq -3910000 path delay     30485
> ptp4l[4488.393]: master offset     -34899 s2 freq -3910000 path delay     30485
> ptp4l[4489.393]: master offset     -47149 s2 freq -3910000 path delay     30485
> ptp4l[4490.393]: master offset     -57433 s2 freq -3910000 path delay     29612
> ptp4l[4491.394]: master offset     -69590 s2 freq -3910000 path delay     29368
> ptp4l[4492.394]: master offset     -81961 s2 freq -3910000 path delay     29612
> ptp4l[4493.394]: master offset     -93790 s2 freq -3910000 path delay     29612
> ptp4l[4494.394]: master offset    -106627 s2 freq -3910000 path delay     29368

Looks like the xilinx driver and/or hw is broken.

Sorry,
Richard

[Linuxptp-users] system1: ptp4l master offset continues to climb: step_threshold 1

[Harold L. <hla...@pi...>]

To Whom It May Concern,

Have a multi-system configuration and on one of the systems 'ptp4l master offset' continues to climb with 'step_theshold 1', might there be some other configuration parameter I am over-looking ?

Thanks,
Harold

system:

               ptp4l.conf:

                              root@zx3-pm3-zynq7:~# cat /usr/bin/ptp4l.conf
                              [global]
                              verbose 1
                              step_threshold 1
                              use_syslog 0
                              [eth0]


               ptp4l:

                              root@zx3-pm3-zynq7:~# /usr/bin/ptp4l -f /usr/bin/ptp4l.conf &

                              ptp4l[4477.362]: port 1: INITIALIZING to LISTENING on INITIALIZE
                              ptp4l[4477.363]: port 0: INITIALIZING to LISTENING on INITIALIZE
                              ptp4l[4478.668]: port 1: new foreign master 000a35.fffe.01225c-1
                              ptp4l[4482.668]: selected best master clock 000a35.fffe.01225c
                              ptp4l[4482.668]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
                              ptp4l[4484.392]: master offset   -2756145 s0 freq -3910000 path delay     30485
                              ptp4l[4485.393]: master offset   -2767595 s1 freq -3910000 path delay     30485
                              ptp4l[4486.393]: master offset     -11892 s2 freq -3910000 path delay     30485
                              ptp4l[4486.393]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
                              ptp4l[4487.393]: master offset     -23642 s2 freq -3910000 path delay     30485
                              ptp4l[4488.393]: master offset     -34899 s2 freq -3910000 path delay     30485
                              ptp4l[4489.393]: master offset     -47149 s2 freq -3910000 path delay     30485
                              ptp4l[4490.393]: master offset     -57433 s2 freq -3910000 path delay     29612
                              ptp4l[4491.394]: master offset     -69590 s2 freq -3910000 path delay     29368
                              ptp4l[4492.394]: master offset     -81961 s2 freq -3910000 path delay     29612
                              ptp4l[4493.394]: master offset     -93790 s2 freq -3910000 path delay     29612
                              ptp4l[4494.394]: master offset    -106627 s2 freq -3910000 path delay     29368



               phc2sys:

                              phc2sys[4598.771]: port 00214a.fffe.000003-1 changed state
                              phc2sys[4598.772]: reconfiguring after port state change
                              phc2sys[4598.773]: selecting CLOCK_REALTIME for synchronization
                              phc2sys[4598.773]: selecting eth0 as the master clock
                              phc2sys[4598.773]: phc offset -10536165 s0 freq   +3833 delay   2814
                              phc2sys[4599.774]: phc offset -10517174 s1 freq  +22810 delay   2838
                              phc2sys[4600.774]: phc offset    -22424 s2 freq    +386 delay   2769
                              phc2sys[4601.775]: phc offset    -22820 s2 freq   -6737 delay   2841
                              phc2sys[4602.775]: phc offset    -16038 s2 freq   -6801 delay   2787
                              phc2sys[4603.775]: phc offset     -9142 s2 freq   -4717 delay   2829
                              phc2sys[4604.776]: phc offset     -4444 s2 freq   -2761 delay   2802
                              phc2sys[4605.776]: phc offset     -1673 s2 freq   -1324 delay   2817
                              phc2sys[4606.777]: phc offset      -312 s2 freq    -465 delay   2775
                              phc2sys[4607.777]: phc offset       149 s2 freq     -97 delay   2835
                              phc2sys[4608.778]: phc offset       297 s2 freq     +96 delay   2802
                              phc2sys[4609.778]: phc offset       197 s2 freq     +85 delay   2799
                              phc2sys[4610.778]: phc offset       137 s2 freq     +84 delay   2790
                              phc2sys[4611.779]: phc offset        63 s2 freq     +51 delay   2811
                              phc2sys[4612.779]: phc offset        49 s2 freq     +56 delay   2754
                              phc2sys[4613.780]: phc offset       -20 s2 freq      +1 delay   2814
                              phc2sys[4614.780]: phc offset        35 s2 freq     +50 delay   2787
                              phc2sys[4615.441]: phc offset        -7 s2 freq     +19 delay   2754

Re: [Linuxptp-users] phc2sys: Bouncing Back and Forth Between Master and Slave

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

On Wed, Sep 16, 2015 at 04:17:55PM +0000, Harold Lapprich wrote:
> In a current design using PTP IEEE-1588 (linuxptp) for clock
> synchronization one of the systems continues to bounce back and
> forth from master to slave and vice versa and the other systems
> maintain original master and slave status determined some time
> ago. From my understanding the hierarchy is created and updated
> automatically by the best master clock (BMC) algorithm that runs on
> every clock ( or PTP IEEE-1588 system), so is this a case where one
> system determines it should be the master and then drops back to
> slave (is this correct operation, if not is there some attribute
> setting for minimizing the occurrence)?

Yes, the BMC determines the role of each port automatically.

And no, there is no attribute to prevent the role changing.  This is
supposed to happen if the GM goes missing, for example.  You *can*
influence the timing of the BMC using logAnnounceInterval and
announceReceiptTimeout.  See the ptp4l man page for details.

Richard