Hi, Based on your comments, we are pulling back this change. For the issues we saw with the clientOnly=1 and boundary_clock_jbod=1, we have sent out a new patch fixing them alone. Thank you for your feedback.
Thanks, Amar B S -----Original Message----- From: Ramana Reddy Sent: 28 April 2021 23:45 To: Richard Cochran <richardcoch...@gmail.com> Cc: Miroslav Lichvar <mlich...@redhat.com>; linuxptp-devel@lists.sourceforge.net; Amar Subramanyam <asubraman...@altiostar.com> Subject: RE: [Linuxptp-devel] [PATCH] To support Ordinary Clock-Subordinate/Slave just a bunch of devices(jbod) feature. -----Original Message----- From: Richard Cochran [mailto:richardcoch...@gmail.com] Sent: 27 April 2021 21:47 To: Ramana Reddy Cc: Miroslav Lichvar; linuxptp-devel@lists.sourceforge.net; Amar Subramanyam Subject: Re: [Linuxptp-devel] [PATCH] To support Ordinary Clock-Subordinate/Slave just a bunch of devices(jbod) feature. CAUTION: This email originated from outside of Altiostar. Do not click on links or open attachments unless you recognize the sender and you are sure the content is safe. You will never be asked to reset your Altiostar password via email. On Tue, Apr 27, 2021 at 03:59:05PM +0000, Ramana Reddy wrote: > <Ramana> As I said, running independent clients defeats the purpose of > BMC algorithm and breaks the ITU-T G.8275.2 Spec compliance. The BMC > algorithm should be run locally on all ports of every ordinary and > boundary clock in a domain. Since it runs continuously, it continually > readapts to changes in the network or the clocks. Pls check section 9.3 in > IEEE1588-2008 Spec for details on BMC algorithm. Also refer to Section 6.7 of > A-BMCA requirements of ITU-T G.8275.2 spec. Did you even read ITU-T G.8275.2 Section 6.7 ? It makes no mention of slaveOnly, but rather masterOnly and localPriority. Ramana> Yes I did and I am not sure if you had gone through it in Ramana> detail. Read through the sections 6.7.1 through 6.7.9 where It talks about the Priority2, clockClass, clockQuality, state decision algorithm, master data set comparison which are all used to Select the Master from Slave perspective. You have not clearly identified a problem with linuxptp WRT G.8275.2. If there is a problem, please state it. Ramana> Although we tried mentioning earlier at high level, seems like Ramana> you still haven't understood. Refer the attached document Ramana> listing the existing issues with jbod_boundary_clock and Client only configuration. See if it helps. We can do a quick 30 mins call if required if you still have questions on the issues identified with G.8275.1/G.8275.2 profile BMCA selection. > > <Ramana> I believe Ordinary Clock can have multiple ports No, your belief is incorrect. The number of ports differentiates OC from BC. In fact, that is the only difference. > <Ramana> Pls refer my earlier reply for why we need to run single ptp4l > instance with multiple ports in OC mode. You _seem_ to be proposing a new and different state machine, not specified by 1588 or G.8275.2. If you want to do that, fine, but please develop some kind of design document that explains both the motivation and the theory of operation. Then, you can provide the implementation in the modular way that does not deface the linuxptp architecture. Hint: p->state_machine = clock_slave_only(clock) ? ptp_slave_fsm : ptp_fsm; Ramana> Our intention is not to propose anything outside Ramana> G.8275.1/G.8275.2/IEEE 1588-2008 spec but try to align with what is mentioned in the spec and fix the issues breaking the spec . Probably I might need a separate discussion on this if we agree on existing issues and then take care of comments in the patch as few of them valid comments like not to add any special handling in PTP stack. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
