See my response inline:
Thanks, Ramana -----Original Message----- From: Miroslav Lichvar [mailto:mlich...@redhat.com] Sent: 27 April 2021 20:59 To: Ramana Reddy Cc: 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 Sat, Apr 24, 2021 at 06:01:46AM +0000, Ramana Reddy wrote: > <Ramana> Thanks. What I think is running multiple ptp4l instances might > defeat the purpose of using BMCA as the chosen ptp4l > Instance might not be carrying the best clock compared to other ptp4l > instances. Alternatively we might have to bring in > Additional Intelligence(similar to BMCA) to monitor bunch of ptp4l instances > to pick best one dynamically. An advantage of having multiple independent clients is that you can better detect failures in synchronization and avoid corrupting the other clocks. <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. > <Ramana> I believe Ordinary Clock can have multiple ports and in such cases > only one of the ports will be in Client/Slave mode and > Other ports shall be either in Listening or passive mode based on whether the > other ports are receiving PTP traffic or > not. The specification defines an ordinary clock as "A PTP Instance that has a single PTP Port in its domain and maintains the timescale used in the domain." If you run ptp4l with multiple specified interfaces, it cannot be an ordinary clock. The boundary_clock_jbod and clientOnly options don't matter here. <Ramana> Pls refer my earlier reply for why we need to run single ptp4l instance with multiple ports in OC mode. > Also IMHO port state PASSIVE doesn’t seem to be tied to a specific clock > mode(BC/OC) in the standard. Right. I read the original patch+report again and it's not clear to me why you need the port to be in the passive state. I tried --boundary_clock_jbod=1 --clientOnly=1 with two interfaces and it seems to be switching them between the LISTENING and UNCALIBRATED/SLAVE states as expected. <Ramana> This I believe was explained in detailed on what are the existing issues, design choices we have, Motivation for the new changes. Pls refer attached mail from Amar. -- Miroslav Lichvar
--- Begin Message --->But you haven't even identified a problem. clientOnly and boundary_clock_jbod >work just fine together: 1. Using boundary_clock_jbod has few issues which weren’t mentioned earlier(see mail trail for the issues). Also boundary_clock_jbod might not be right term to be used for Ordinary Clock Client/Slave/Sub-ordinate modes. Boundary Clock and Ordinary are two different clocks. So to tackle the problems we have today, we have evaluated two approaches: A) Rename existing boundary_clock_jbod to something more meaningful to convey that its applicable for OC/BC modes( Something like jbod_clock) and then define separate options for boundary clock just like existing ClientOnly/Slave only Options. Then fix existing issues we have today. B) Define separate config option for Ordinary clock Slave/Client modes : slave_clock_job/client_clock_jbod and handle the multiple client port’s case. We have evaluated both and decided to take 2nd approach to keep it separate, clean and address the issues pertaining to each clock mode separately. 2. Below are the list of issues we have today for Boundary clock jbod with clientOnly option a. When the redundant port part of the clock bundle stops receiving Announce packets, announce timeout occurs continuously and triggers BMCA which affects the port which is already SLAVE Example: ./ptp4l -f ~/config_ptp_8275_1.conf -i sriov0 -i eno2 2 -H -m option slaveOnly is deprecated, please use clientOnly instead ptp4l[627776.931]: selected /dev/ptp0 as PTP clock ptp4l[627776.931]: port 2 (eno2): just a bunch of devices ptp4l[627776.952]: port 1 (sriov0): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[627776.972]: port 2 (eno2): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[627776.972]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[627776.972]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[627776.972]: port 1 (sriov0): received SYNC without timestamp ptp4l[627777.036]: port 1 (sriov0): new foreign master c4b239.fffe.483fbf-80 ptp4l[627777.288]: selected best master clock 9c65ee.fffe.76e665 ptp4l[627777.288]: updating UTC offset to 37 ptp4l[627777.288]: port 1 (sriov0): LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[627777.444]: selected best master clock 9c65ee.fffe.76e665 ptp4l[627777.444]: updating UTC offset to 37 ptp4l[627777.926]: selected best master clock 9c65ee.fffe.76e665 ptp4l[627777.926]: updating UTC offset to 37 ptp4l[627778.263]: port 1 (sriov0): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[627778.328]: selected best master clock 9c65ee.fffe.76e665 ptp4l[627778.328]: updating UTC offset to 37 ptp4l[627778.328]: rms 7 max 14 freq -605 +/- 0 delay 616 +/- 2 ptp4l[627778.744]: selected best master clock 9c65ee.fffe.76e665 ptp4l[627778.744]: updating UTC offset to 37 ptp4l[627778.744]: clockcheck: clock jumped backward or running slower than expected! ptp4l[627778.744]: port 1 (sriov0): SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l[627778.888]: clockcheck: clock jumped forward or running faster than expected! ptp4l[627779.161]: selected best master clock 9c65ee.fffe.76e665 ptp4l[627779.161]: updating UTC offset to 37 ptp4l[627779.264]: clockcheck: clock jumped forward or running faster than expected! ptp4l[627779.335]: rms 5 max 11 freq -594 +/- 5 delay 614 +/- 1 ptp4l[627779.593]: selected best master clock 9c65ee.fffe.76e665 ptp4l[627779.593]: updating UTC offset to 37 ptp4l[627779.976]: selected best master clock 9c65ee.fffe.76e665 ptp4l[627779.976]: updating UTC offset to 37 b. As the other PTP redundant ports part of bundle are in LISTENING state, BMCA will not be able to select best master when there is best clock carried in the other ports (other than the port which is already locked). Please refer to IEEE1588 section 9.2.4 where they mention the definition of LISTENING and PASSIVE state interpretations. Two tackle the above two problems, changes done are as follows 1. We have changed the state machine to move the port to PASSIVE state when the new configuration parameter is active. 2. Stop announce timeouts on redundant ports. 3. Existing boundary_clock_jbod in BC mode was tested to ensure that there are no other breakages with the proposed changes. > 1. Your are changing the core state machines from IEEE 1588. We don't > deviate from the standard, especially not from the critical foundation. > If we do deviate, then only on minor points and only with a very > strong reason. However, you have given no justification at all for > this change. According to section 9.2.4 table 27 in IEEE1588 2008 LISTENING state means that it is waiting for announce packets or waiting for announce receipt timer to expire PASSIVE state means that the port is receiving announce packets, but BMCA determined that port to be in PASSIVE state and hence will not communicate. For redundant ports the state is LISENING in existing implementation when the port is receiving announce packets, instead of PASSIVE. Thanks, Amar B S From: Richard Cochran<mailto:richardcoch...@gmail.com> Sent: 21 April 2021 22:36 To: Amar Subramanyam<mailto:asubraman...@altiostar.com> Cc: linuxptp-devel@lists.sourceforge.net<mailto:linuxptp-devel@lists.sourceforge.net> 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 Thu, Apr 15, 2021 at 11:16:00AM +0300, Amar Subramanyam via Linuxptp-devel wrote: > This change brings slave clock jbod feature which allows ptp4l to work as a > Ordinary Subordinate/Slave clock using "just a bunch of devices" that are not > synchronized to each other but a collection of clocks synchronized by an > external > source.The best master will be decided by BMCA among the collection of the > clocks. > This feature gets enabled by ptp4l config option: slave_clock_jbod and > by default it is disabled. This patch is unacceptable for two reasons... > bmc.c | 4 ++++ > clock.c | 14 ++++++++++++++ > clock.h | 7 +++++++ > config.c | 1 + > designated_fsm.c | 4 ++-- > designated_fsm.h | 6 ++++-- > fsm.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++----- 1. Your are changing the core state machines from IEEE 1588. We don't deviate from the standard, especially not from the critical foundation. If we do deviate, then only on minor points and only with a very strong reason. However, you have given no justification at all for this change. 2. You hack your feature all over the place, like: if (my_special_flag) { do_my_special_thing(); } This a both red flag and a code smell. Changes must respect the architecture. If the architecture needs changes, then you must change it, step by step. But you haven't even identified a problem. clientOnly and boundary_clock_jbod work just fine together: ./ptp4l -m -q --clientOnly=1 --boundary_clock_jbod=1 -i eth6 -i eth4 -i eth3 ptp4l[94622.316]: selected /dev/ptp1 as PTP clock ptp4l[94622.316]: port 2 (eth4): just a bunch of devices ptp4l[94622.316]: port 3 (eth3): just a bunch of devices ptp4l[94622.318]: port 1 (eth6): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[94622.319]: port 2 (eth4): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[94622.320]: port 3 (eth3): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[94622.320]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[94622.320]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[94624.185]: port 1 (eth6): new foreign master 00e00c.fffe.bce560-1 ptp4l[94628.224]: selected best master clock 00e00c.fffe.bce560 ptp4l[94628.224]: port 1 (eth6): LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[94628.825]: selected best master clock 00e00c.fffe.bce560 ptp4l[94629.136]: selected best master clock 00e00c.fffe.bce560 ptp4l[94629.767]: master offset 1619024566521062408 s0 freq +0 path delay 50273 ptp4l[94630.787]: master offset 1619024566520947488 s1 freq -112695 path delay 50273 ptp4l[94631.806]: master offset -5796 s2 freq -118491 path delay 50273 ptp4l[94631.806]: port 1 (eth6): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[94632.826]: master offset 50923 s2 freq -63510 path delay -555 ptp4l[94633.846]: master offset 899 s2 freq -98258 path delay -555 ptp4l[94634.866]: master offset -15796 s2 freq -114683 path delay 1392 ptp4l[94635.885]: master offset -12462 s2 freq -116088 path delay 27 ptp4l[94636.058]: selected best master clock 00e00c.fffe.bce560 ptp4l[94636.130]: selected best master clock 00e00c.fffe.bce560 ptp4l[94636.905]: master offset -8424 s2 freq -115788 path delay -555 ptp4l[94637.925]: master offset -5263 s2 freq -115154 path delay -555 ptp4l[94638.945]: master offset -2474 s2 freq -113944 path delay -762 ptp4l[94639.965]: master offset -1157 s2 freq -113370 path delay -762 ptp4l[94640.984]: master offset -532 s2 freq -113092 path delay -658 ptp4l[94642.004]: master offset -7 s2 freq -112726 path delay -658 Thanks, Richard
--- End Message ---
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
