> 12.10.2022 14:38 Erez <erezge...@gmail.com> wrote: > > > > > > > > > > On Wed, 12 Oct 2022 at 13:48, Jakub Raczynski > <j.raczyn...@elpromaelectronics.com > <mailto:j.raczyn...@elpromaelectronics.com>> wrote: > > Current implementation of flag "-a -rr" for phc2sys selects CLOCK_REALTIME > > for > > both directions of PTP synchronization. This may be impractical for Network > > > Not really sure what you are talking about, it can be used to "synchro‐ > nize the system clock to a PTP hardware clock (PHC)". > Which means it updated the PHC and only read the CLOCK_REALTIME. > Why do you need to "protect" the CLOCK_REALTIME further? > The problem is simple: flag "-a -rr" sets CLOCK_REALTIME to be both source and receiver, depending on the portState. I find it a bit lacking, as it would be really useful if we could use CLOCK_REALTIME as source only and ntpshm as receiver (depending on the portState of course). > > > Time Servers which use alternative sources of synchronization, that > > usuallyhave clock adjusted by ntpd/chrony. > > For gPTP Grandmaster in Time Servers the most optimal solution would be to > > > What do you mean by "gPTP"? > Do you mean Generalized Precision Time Protocol (gPTP, IEEE 8201.AS > <http://8201.AS>)? > There is a project that uses the gPTP name: https://github.com/Avnu/gptp > Correct, I mean IEEE 802.1AS. But in fact, it is just where the issue can be observed, that is device being able to be 802.1AS Grandmaster, being able to be synchronized both ways rather than clear Master/Slave role. > > > > > use CLOCK_REALTIME to synchronize phc when in Master state and stopping > > synchronization when in Slave state. This would allow to combine > > internal Time Server sources (using ntpd/chrony) with phc as Master/Slave. > > > > Implementation of two-way gPTP synchronization requires two phc2sys > > instances: > > - one synchronizing CLOCK_REALTIME->phc when in Master (phc2sys -a -rr), > > - second synchronizing phc->ntpshm when in Slave state (phc2sys -a -r -E > > ntpshm). > > > Looks like a great idea, why is it related to "double" read-only of the > system clock? > Seems you want a flag that toggle the phc2sys based on the ptp4l state, > whether it is source (master) or it is a client (slave). > I think that a condition flag like that is better than using a 3 x 'r', which > is quite confusing. > > > I think something like: > 1. Normal mode, Sys clock => PHC or PHC => Sys clock > 2. PHC only, Sys clock => PHC if ptp4l is master (source) > 3. both, Sys clock => PHC if ptp4l is source (maste) or PHC => Sys clock > if ptp4l is client (slave) > > Probably you are right that it would be much cleaner by using separate flag. I used tripple -r to indicate it dependance on autoconfiguration option, but in fact it is not intuative as you mentioned. This patch allows to use CLOCK_REALTIME as time source for phc but for Slave it allows to synchronize system via ntpd/chrony daemon. All optioms you mentioned are implemented from what i see, but in my case I want to use different source and receiver, without "-w" or "-O" flag that i find a bit lacking compared to autoconfiguration. > > > > > To address this issue, the additional (triple) '-r' flag was implemented. > > When using '-a -rrr' CLOCK_REALTIME will be used as "source only". > > This is probably better solution than usage of separate program detecting > > current portState of PTP. > > > I do not understand how this solves the problem. > As phc2sys does communicate with ptp4l, it can probe the portState and you do > not need an additional program for that. > > > Although in most cases we want to make the decision, who is the > master/grandmaster of our PTP domain, > As PTP does work with "priorities", it means that in practice, any PTP entity > with a higher value may become the master. So a feature like that in phc2sys > does make sense :-) > > > Erez The problem is that in current version it is quite impossible to have > synchronization from PHC->ntpshm if Slave and CLOCK_REALTIME->PHC if Master. It is in fact continuation of https://sourceforge.net/p/linuxptp/mailman/message/37683362/ by me. It was suggested with current implementation i would have to use two phc2sys instances or use separate program to monitor portState. Sadly, just two phc2sys instances do not cut it. Best regards Jakub Raczynski
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
