-----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 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 you
still haven't understood. Refer the attached document 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 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
issues_with_ptp4l_boundary_clock_client_only_mode_with_multiple_ports.docx
Description: issues_with_ptp4l_boundary_clock_client_only_mode_with_multiple_ports.docx
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
