linuxptp-users Mailing List for linuxptp (Page 125)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

On Tue, 2015-08-18 at 14:54 +0000, Harold Lapprich wrote:
> Jake,
> 
> Thanks for the detailed reply. My apologies but I need to iterate on
> this one more time, want to keep master/slave with respect to the
> system-network and NOT the PTP-network (for example the PTP-network
> is a slave to the system-network master).
> 

It doesn't matter what you want. The terminology is what it means. You
changing it is confusing the discussion.

The PTP network derives it's time from somewhere, be that GPS, NTP,
it's own crystal on the grandmaster, whatever. This is not relevant to
PTP. However, how you transition this time in is, sure.

> Want to drop the 'ptp4l'  scenario of system-network master from the
> discussion to simplify things, another words PTP-network is always a
> slave to the system-network or to NTP/ntpd master:
> 

PTP always derives it's time from some source.

> 1.      NTP --> system clock -> phc2sys -> ptp4l (master) -> network
> out to other PTP slaves --> ptp4l (slave) --> phc2sys --> system
> clock (No NTP here)
> 

When PTP is a master node, it gets its time from some source. In this
case, NTP feeds the system clock, and phc2sys feeds the PTP master
hardware clock which then feeds the PTP network.

> 
> 
> Timemaster is slave-only. That is, PTP slave. The timemaster
> configures such that it's ptp4l node will *never* become master
> clock. The reason for this is because phc2sys only supports ntpshm
> segment clock going from slave mode, and would have to switch servos
> which no one has written code for.
> 

Time master is slaveOnly, that is, PTP will always be slave, so it will
always be creating a SHM segment clock that may (or may not) feed PTP.

> For example:
> ptp4l -i eth0
> phc2sys -a -r -r
> chronyd 'local stratum 1' 'allow'
> 
> The example configuration file shows 'ptp4l' being able to assume
> GrandMaster but NOT system-network master due to a clock update
> 

The example configuration file for PTP allows it perfectly to become
GrandMaster and feed the system time. The issue you have is that when
this happens you STILL have NTP configured to set the host clock. Your
whole  issue is that NTP is not aware of this and tries to reset system
clock instead of serving that time. You need to fix NTP to assume that
the system clock is absolute. 

> conflict between 'phc2sys' and the NTP/ntpd deamon (along with the
> SHM or shared memory code issue you mentioned). Therefore 'phc2sys'
> must always be a slave passing updates to 'ptp4l' which is
> GrandMaster to the PTP-network?
> 

This only happens when ptp4l is in "slave" mode. phc2sys will only
write the system clock (when configured in -a -r mode) when ptp4l is
*receiving* time from the network. Ie; it is deriving its time source
from some other GrandMaster clock.

> If 'ptp4l' can NOT become GrandMaster there would be no way of
> synchronizing system-network clock with PTP-network clock.
> 

Sure there is. Not every node has to be configured the same way. You
configure one node manually with high values for its clock source and
then it is elected GrandMaster clock. Then the other nodes are
slaveOnly so they will never send announce messages, thus will never be
selected.

The issue is that the default NTP keeps trying to reset the clock after
phc2sys configures it.

If ptp4l is in "master" (or even the GrandMaster of a larger network)
you can configure NTP to write the system clock, then phc2sys to tune
the hardware clock running ptp4l to the system clock time source. Thus,
ptp4l will serve (or as above, feed) the PTP network with this time
source.

If ptp4l is in "slave" mode it receives PTP time from the PTP network
and tunes its internal clock. Then phc2sys feeds the system time from
the internal clock.

However, by default, ntpd is also trying to feed the system clock via
its own mechanism. This is the conflict. Two sources controlling the
clock.

Thus, timemaster gets around this by not having phc2sys feed the system
clock, but instead feed an SHM segmnent which ntpd/chronyd read to use
as a possible input, along with NTP, and feed the system time from
whichever is best.

The issue is that phc2sys can't switch between these two modes, because
phc2sys would have to change servos which is not supported.

Regards,
Jake

> Thanks,
> Harold
> 
> 
> 
> 
> -----Original Message-----
> From: Keller, Jacob E [mailto:jac...@in...] 
> Sent: Monday, August 17, 2015 6:14 PM
> To: mli...@re...; Harold Lapprich <
> hla...@pi...>
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] Grandmaster Auto-Negotiation and
> Reconfiguration of phc2sys to ptp4l Synchronization
> 
> Hello again,
> 
> I think you're still missing something.
> 
> Timemaster is slave-only. That is, PTP slave. The timemaster
> configures such that it's ptp4l node will *never* become master
> clock. The reason for this is because phc2sys only supports ntpshm
> segment clock going from slave mode, and would have to switch servos
> which no one has written code for.
> 
> Thus, timemaster will only ever setup PTP slaves. Ie: these nodes can
> never be elected as the master clock in the PTP network at all.
> 
> I'm not sure what you mean by "entireSystem-network".
> 
> Hopefully we are clear here, and "master/slave" designation only
> refers to PTP network.
> 
> You can decide what the SOURCE of the time on the ptp master is,
> either GPS, NTP, etc. That's not of concern to PTP network.
> 
> timemaster lets you configure a ptp4l *slave* to feed a time clock to
> chronyd such that chronyd will either use NTP or PTP time whichever
> one is considered more accurate.
> 
> I don't believe timemaster configures chronyd to actually *serve* the
> PTP time onto the NTP protocol, but Miroslav can correct me if I am
> wrong.
> 
> If you have a PTP master node, then it needs to get time from
> somewhere. Usually this would be from say, NTP which writes the
> master clock then the phc2sys writes the hardware clock onboard the
> ethernet device using the system clock as a reference.
> 
> In reverse, the ptp4l writes the hardware clock, then phc2sys writes
> the system clock tuned to the hardware clock. But by default ntpd and
> chronyd are configured to write the system clock and thus we have two
> processes writing to the system clock, which results in the
> clock_check errors you saw at the beginning of this thread.
> 
> Those are the two flows in regards to ptp4l clock, system clock and
> phc2sys and chronyd's roles.
> 
> phc2sys can also provide a "SHM" reference to chronyd WITHOUT writing
> the system clock, and chronyd will use this as a reference to tune
> the system clock. This however can't work when phc2sys must write the
> hardware clock, as chronyd and ntpd don't know of the hardware clock.
> Thus, phc2sys can't swap between these modes, since it is not
> designed to change servos from the PI servo to the NTPSHM servo mid
> run, thus it can't automatically switch if the node is selected as
> master. This is why timemaster configures ptp4l as slave only.
> 
> Regards,
> Jake
> 
> On Mon, 2015-08-17 at 21:56 +0000, Harold Lapprich wrote:
> Jake,
> 
> Thanks for clarifying the function of the 'timemaster', a program
> purely for configuring other programs. Going to go through your
> response 1 line item at a time to simplify my response and clarify my
> understanding. Getting specific terms in place for discussing this
> matter has been helpful.
> 
> So “master” means serving time out over the entireSystem-network NOT
> the PTP-network (intentionally separating entireSystem-network and
> PTP-network). When 'master' is used it is with regards to the
> entireSystem-network and GrandMaster is used with regards to the PTP
> -network.
> 
> 
> 
> Miroslav mentioned that 'timemaster' is PTP slave only and starts
> ptp4l with the slaveOnly option, so it can't become a master and that
> didn't add up for me. I believe master and GrandMaster were getting
> mixed up here (the slaveOnly options is for GrandMaster and not
> master).
> 
> "No, timemaster is currently PTP slave only. It starts ptp4l with the
> slaveOnly option, so it can't become a master. With current phc2sys
> it wouldn't work anyway. It would need to be modified to switch
> between two servos, NTP SHM when the PTP clock is synchronized and a
> real servo when the system clock is the source."
> 
> 
> "For example:
> 
> ptp4l -i eth0
> 
> phc2sys -a -r -r
> 
> chronyd 'local stratum 1' 'allow'"
> 
> This example provided 'ptp4l -i eth0' shows ptp4l starting withOUT
> the slaveOnly option '-s' so in this case 'ptp4l' can assume
> GrandMaster of the PTP-network (again it appears to be a mixing of
> the terms master/entireSystem-network and Grandmaster/PTP-network)?
> 
> 
> 
> Thanks for the flow diagram in your response is most helpful, I was
> thinking 'timemaster' did more than just configure programs:
> 
> 
> 1.      NTP --> system clock -> phc2sys -> ptp4l (master) -> network
> out to other PTP slaves --> ptp4l (slave) --> phc2sys --> system
> clock (No NTP here)
> 
>         As you mentioned ptp4l(master) is the GrandMaster of the PTP
> -network but NOT the 'master' serving time out over the entireSystem
> -network. And ptp4l(master) is a slave to the NTP daemon via
> 'phc2sys'.
> 
> So having 'phc2sys' use the system clock to update 'ptp4l' isn't an
> issue since the system clock is only being updated by one program the
> ntpd deamon.
> 
> 
> 
> 
> 
> OK we are now discussing the following flow configuration (if ptp4l
> was to be the GrandMaster/PTP-network and 'master' of the
> entireSystem-network):
> 
> 
> 1.      NTP< --system clock<- - phc2sys<-- ptp4l (master) -> network
> out to other PTP slaves --> ptp4l (slave) --> phc2sys --> system
> clock (No NTP here)
> 
> To perform the NTP syncs PTP master setup, you need to do something
> like:
> 
> 
> 1.      Configure NTP to control the system clock
> 
> 2.      Configure phc2sys to drive the PTP hardware clock on your
> device. Your problem is that this behavior does not allow automatic
> configuration, because phc2sys can’t switch servos while running.
> Since it will attempt to drive the system time 100% when tuning
> system time to ptp4l you get the result where NTP attempts to
> interfere.
> 
> a.      If you do this manually, however, then it won’t automatically
> switch directions for you
> 
> In this case the system running the NTP server (ntpd deamon) would be
> taking system time and broadcasting it across the entireSystem
> -network or the 'master' using the Network Timing Protocol (NTP).
> Also running on this same system would be the GrandMaster/PTP
> -network. There would be NO conflict changing the system clock since
> 'phc2sys' would be the only program  and the ntpd daemon would be
> broadcasting it across the entireSystem-network, correct?
> 
> But there is an issue should the GrandMaster fail (removed or powered
> down) in that both the NTP server and GrandMaster would be loss. In
> this case the remaining slave/PTP-network devices would auto
> -negotiate another GrandMaster but no NTP server would co-exist. So a
> program would need to be running in the background on all systems
> checking for a switch from slave to a GrandMaster/PTP-network device
> and bring a NTP server up upon detecting a switch from slave to
> GrandMaster, correct?
> 
> 
> 
> 
> 
> It is possible your device is good enough to actually be the grand
> -master of time, in which case it could be used to set the system
> time as well. But that would really only occur if your PTP node is a
> dedicated clock, and I can’t say I have experience setting one of
> those up.
> 
> This is a good point and I don't have an answer right now. If just a
> local PTP-network existed then one of the system could be the NTP
> server but way when you have the entire local network covered by PTP.
> 
> 
> Thanks,
> Harold
> 
> 
> 
> 
> 
> From: Keller, Jacob E [mailto:jac...@in...]
> Sent: Monday, August 17, 2015 2:09 PM
> To: Harold Lapprich <hla...@pi...>; Miroslav Lichvar
> <mli...@re...>
> Cc: lin...@li...
> Subject: RE: [Linuxptp-users] Grandmaster Auto-Negotiation and
> Reconfiguration of phc2sys to ptp4l Synchronization
> 
> Hi,
> 
> Timemaster is a program to help simplify the configuration of the
> other programs, in that sense, it doesn’t “do” any of the things on
> its own.
> 
> The flow diagram should be:
> 
> 
> 1.      NTP --> system clock -> phc2sys -> ptp4l (master) -> network
> out to other PTP slaves --> ptp4l (slave) --> phc2sys --> system
> clock (No NTP here)
> 
> If you’re ptp4l is “master” that means it is serving time out the
> network and thus is the only time when NTP should be configured it.
> In this case, ptp4l would function as master on the PTP network, but
> would be the slave of the NTP daemon via phc2sys.
> 
> It is possible your device is good enough to actually be the grand
> -master of time, in which case it could be used to set the system
> time as well. But that would really only occur if your PTP node is a
> dedicated clock, and I can’t say I have experience setting one of
> those up.
> 
> To perform the NTP syncs PTP master setup, you need to do something
> like:
> 
> 
> 1.      Configure NTP to control the system clock
> 
> 2.      Configure phc2sys to drive the PTP hardware clock on your
> device. Your problem is that this behavior does not allow automatic
> configuration, because phc2sys can’t switch servos while running.
> Since it will attempt to drive the system time 100% when tuning
> system time to ptp4l you get the result where NTP attempts to
> interfere.
> 
> a.      If you do this manually, however, then it won’t automatically
> switch directions for you
> 
> I believe that is the crux if your issue here. In addition, I think
> you have the notion of slave/master backwards. Slave means that it is
> receiving time from the network and thus is the “master” time source
> in the system. Master means it is serving time out the network and is
> thus the “slave” to the system time. This dual usage of terminology
> can get confusing.
> 
> Regards,
> Jake
> 
> From: Harold Lapprich [mailto:hla...@pi...]
> Sent: Monday, August 17, 2015 10:16 AM
> To: Miroslav Lichvar
> Cc: Keller, Jacob E; lin...@li...<mailto:
> lin...@li...>
> Subject: RE: [Linuxptp-users] Grandmaster Auto-Negotiation and
> Reconfiguration of phc2sys to ptp4l Synchronization
> 
> Miroslav,
> 
> Thanks again for the quick response, trying to simplify the
> discussion and therefore minimize any mis-understanding by providing
> the following simply flow diagrams:
> 
> Need to support the following 2 scenarios using the 'linuxptp'
> applications but NOT both in the same network configuration (only 1
> of the 2 will exist)
> 
>         1. NTP <---- timemaster <---- system clock <---- phc2sys <---
> - 'ptp4l (master)' ----//---->ptp4l (slaves)---->phc2sys---->system
> clock
> 
>         2. NTP ----> timemaster ----> system clock ----> phc2sys ---
> -> 'ptp4l (master)' ----//----ptp4l (slaves)---->phc2sys---->system
> clock
> 
> Please let me know if the proceeding flow diagrams are NOT correct?
> 
> 
> 
> 
> I. Do you need NTP as a time source? Or just serve time over NTP? The
> former conflicts with your requirement to allow ptp4l to be a master
> as phc2sys would need to be the process that synchronizes the clock
> and not chronyd/ntpd.
> 
> Want the ability to have NTP as a time source or serve time over NTP
> but not both at the same time (therefore need the capability to do
> both, 1: when local network configuration is standalone then a
> network server will be locked to PTP time via PTP-->NTP, and 2: when
> the local network is a subset of a larger network and therefore NTP -
> -> PTP). The configuration will be a known entity and therefore the
> 'linuxptp' application configuration files created appropriately this
> is NOT something that needs to happen automatically.
> 
> 
> 
> 
> II. The former conflicts with your requirement to allow ptp4l to be a
> master as phc2sys would need to be the process that synchronizes the
> clock and not chronyd/ntpd.
> 
> It is my understanding that 1 of the PTP clients has to be a master
> (ptp4l master) but the master can be locked to the system clock by
> phc2sys (this is what I am currently doing, ptp4l -i eth0 and phc2sys
> -a -r -r).
> Then 'timemaster' would be used to synchronize the system clock to
> NTP.
> 
>         1. NTP <---- timemaster <---- system clock <---- phc2sys <---
> - 'ptp4l (master)' ----//---->ptp4l (slaves)---->phc2sys---->system
> clock
> 
> 
> 
> 
> III. The problem is that when phc2sys is configured to feed
> chronyd/ntpd, it is not able to synchronize the PTP clock in the
> reverse direction when ptp4l is master.
> 
> It is my understanding that the ptp4l(master) will be driving phc2sys
> to drive the system clock (1: 'ptp2l -i eth0 -m', 'phc2sys -a -r -r 
> -m'; 2: 'ptp4l -i eth0 -s -m', 'phc2sys -a -r -m'). Or another words
> PTP master clock will be driving everything.
> 
>         1. NTP <---- timemaster <---- system clock <---- phc2sys <---
> - 'ptp4l (master)' ----//---->ptp4l (slaves)---->phc2sys---->system
> clock
> 
> 
> 
> 
> Jake Keller
> 
> If you run ptp4l on all your systems, and each one also running
> phc2sys, it will:
> 
> on system which is "master"
> 
> phc2sys will drive the ptp4l hw clock based on local time
> 
> ptp4l will sync time out the network using PTP
> 
> on systems which are not master
> 
> ptp4l will sync time in from network to hw clock
> 
> phc2sys will sync hw clock to CLOCK_REALTIME.
> 
> 
> Also Jake Keller response: "But if you want to also use NTP as a
> clock source, then you need to use timemaster, as otherwise phc2sys
> and ntpd will interfere with each other." Dosen't this imply that
> using 'timemaster' will remove this issue (phc2sys will synchronize
> the PTP (master) clock to the system clock and NTP will synchronize
> the system clock)?
> 
> 
> Harold
> 
> 
> 
> 
> -----Original Message-----
> From: Miroslav Lichvar [mailto:mli...@re...]
> Sent: Monday, August 17, 2015 11:54 AM
> To: Harold Lapprich <hla...@pi...<mailto:
> hla...@pi...>>
> Cc: Keller, Jacob E <jac...@in...<mailto:
> jac...@in...>>; lin...@li...<mail
> to:lin...@li...>
> Subject: Re: [Linuxptp-users] Grandmaster Auto-Negotiation and
> Reconfiguration of phc2sys to ptp4l Synchronization
> 
> On Mon, Aug 17, 2015 at 02:14:36PM +0000, Harold Lapprich wrote:
> >        "If you run ptp4l on all your systems, and each one also
> > running phc2sys, it will:
> > 
> >        on system which is "master"
> > 
> >                phc2sys will drive the ptp4l hw clock based on local
> > time
> > 
> >                ptp4l will sync time out the network using PTP
> > 
> >        on systems which are not master
> > 
> >                ptp4l will sync time in from network to hw clock
> > 
> >                phc2sys will sync hw clock to CLOCK_REALTIME.
> > 
> >        But if you want to also use NTP as a clock source, then you
> > need to use timemaster, as otherwise phc2sys and ntpd will
> > interfere with each other."
> 
> Strictly speaking you just need to configure phc2sys to use the NTP
> SHM servo to feed chronyd/ntpd so they can select the best source or
> combine multiple sources and synchronize the clock. That's how
> phc2sys is configured by timemaster.
> 
> Do you need NTP as a time source? Or just serve time over NTP? The
> former conflicts with your requirement to allow ptp4l to be a master
> as phc2sys would need to be the process that synchronizes the clock
> and not chronyd/ntpd.
> 
> If you just need to serve NTP, you can configure chronyd/ntpd to not
> synchronize the clock and keep phc2sys in the control of the clock.
> 
> > So when NTP is to be the clock source (and vice versa)  then
> > 'timermaster' is needed because phc2sys and ntpd will interfere
> > with one another. Now the problem is GrandMaster failure, if I
> > understand you correctly when another PTP system on the network
> > becomes the GrandMater 'timemaster' will NOT automatically
> > reconfigure and start using NTP as the clock source (using
> > timemaster to start PTP configuration on all systems on the PTP
> > network)?
> 
> The problem is that when phc2sys is configured to feed chronyd/ntpd,
> it is not able to synchronize the PTP clock in the reverse direction
> when ptp4l is master.
> 
> > If this is the case then one would have to have another application
> > running in the background to detect the switch, create the
> > appropriate 'timemaster' configuration file and start?
> 
> There is currently no way to configure timemaster to serve local time
> over PTP. phc2sys would need to allow that first.
> 
> --
> Miroslav Lichvar
> 

2012	Jan	Feb (10)	Mar (47)	Apr	May (26)	Jun (10)	Jul (4)	Aug (2)	Sep (2)	Oct (20)	Nov (14)	Dec (8)
2013	Jan (6)	Feb (18)	Mar (27)	Apr (57)	May (32)	Jun (21)	Jul (79)	Aug (108)	Sep (13)	Oct (73)	Nov (51)	Dec (24)
2014	Jan (24)	Feb (41)	Mar (39)	Apr (5)	May (6)	Jun (2)	Jul (5)	Aug (15)	Sep (7)	Oct (6)	Nov	Dec (7)
2015	Jan (27)	Feb (18)	Mar (37)	Apr (8)	May (13)	Jun (44)	Jul (4)	Aug (50)	Sep (35)	Oct (6)	Nov (24)	Dec (19)
2016	Jan (30)	Feb (30)	Mar (23)	Apr (4)	May (12)	Jun (19)	Jul (26)	Aug (13)	Sep	Oct (23)	Nov (37)	Dec (15)
2017	Jan (33)	Feb (19)	Mar (20)	Apr (43)	May (39)	Jun (23)	Jul (20)	Aug (27)	Sep (10)	Oct (15)	Nov	Dec (24)
2018	Jan (3)	Feb (10)	Mar (34)	Apr (34)	May (28)	Jun (50)	Jul (27)	Aug (75)	Sep (21)	Oct (42)	Nov (25)	Dec (31)
2019	Jan (39)	Feb (28)	Mar (19)	Apr (7)	May (30)	Jun (22)	Jul (54)	Aug (36)	Sep (19)	Oct (33)	Nov (36)	Dec (32)
2020	Jan (29)	Feb (38)	Mar (29)	Apr (30)	May (39)	Jun (45)	Jul (31)	Aug (52)	Sep (40)	Oct (8)	Nov (48)	Dec (30)
2021	Jan (35)	Feb (32)	Mar (23)	Apr (55)	May (43)	Jun (63)	Jul (17)	Aug (24)	Sep (9)	Oct (31)	Nov (67)	Dec (55)
2022	Jan (31)	Feb (48)	Mar (76)	Apr (18)	May (13)	Jun (46)	Jul (75)	Aug (54)	Sep (59)	Oct (65)	Nov (44)	Dec (7)
2023	Jan (38)	Feb (32)	Mar (35)	Apr (23)	May (46)	Jun (53)	Jul (18)	Aug (10)	Sep (24)	Oct (15)	Nov (40)	Dec (6)

linuxptp-users Mailing List for linuxptp (Page 125)

PTP IEEE 1588 stack for Linux

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