Re: [Linuxptp-devel] [PATCH 00/10] Slave event monitoring
> -Original Message- > From: Richard Cochran > Sent: Thursday, May 28, 2020 1:35 PM > To: Keller, Jacob E > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH 00/10] Slave event monitoring > > On Thu, May 28, 2020 at 05:07:05PM +, Keller, Jacob E wrote: > > > Presumably, other implementations won't support this non-portable > > TLV. Is there any part of our implementation that ought to support > > the official standard? > > Yes, and this series already implements the official > SLAVE_RX_SYNC_TIMING_DATA. Nothing prevents us adding the official > variant of SLAVE_TX_EVENT_TIMESTAMPS in the future, if anybody really > wants it. > > > Or should we attempt to push for improving the standard? > > Also yes. Already there was something missing from the standard for > this optional feature, and I did share that with the IEEE working > group already. > > > I suppose in some sense, since you're only sending this data over > > the local unix domain socket it's less of a concern? > > Right. We can implement what is useful now and lead the way for > others to follow. > > Thanks, > Richard Sounds good. If someone cares in the future they could implement the standard one when they want it for interop. Thanks, Jake ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 00/10] Slave event monitoring
On Thu, May 28, 2020 at 05:07:05PM +, Keller, Jacob E wrote: > Presumably, other implementations won't support this non-portable > TLV. Is there any part of our implementation that ought to support > the official standard? Yes, and this series already implements the official SLAVE_RX_SYNC_TIMING_DATA. Nothing prevents us adding the official variant of SLAVE_TX_EVENT_TIMESTAMPS in the future, if anybody really wants it. > Or should we attempt to push for improving the standard? Also yes. Already there was something missing from the standard for this optional feature, and I did share that with the IEEE working group already. > I suppose in some sense, since you're only sending this data over > the local unix domain socket it's less of a concern? Right. We can implement what is useful now and lead the way for others to follow. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 00/10] Slave event monitoring
> -Original Message- > From: Richard Cochran > Sent: Sunday, May 24, 2020 7:53 PM > To: linuxptp-devel@lists.sourceforge.net > Subject: [Linuxptp-devel] [PATCH 00/10] Slave event monitoring > > The IEEE 1588 v2.1 standard introduces a new optional feature known as > slave event monitoring. This feature defines three new TLVs. > > 1. SLAVE_RX_SYNC_TIMING_DATA > >This TLV provides the time stamps T1 and T2 from the message >exchange between master and slave. > > 2. SLAVE_TX_EVENT_TIMESTAMPS > >This provides the T3 time stamp only. > > 3. SLAVE_RX_SYNC_COMPUTED_DATA > >This TLV provides the estimated offset and path delay. > > The standard leaves the mechanism for enabling and configuring this > feature as implementation-defined. This series implements slave > monitoring by offering a configuration option that specifies a UDS > address, allowing a local client such as the 'pmc' program to monitor > the time stamps. > > While this series implements the first TLV verbatim, the second TLV > makes little sense as specified in the standard, because it omits the > T4 time stamp. For this reason a custom TLV is used that provides > both T3 and T4. The third TLV is not implemented here because it is > redundant, merely providing data already available in other management > messages. Presumably, other implementations won't support this non-portable TLV. Is there any part of our implementation that ought to support the official standard? Or should we attempt to push for improving the standard? I.e. while I agree that adding the the T4 timestamp is good, I'd like to make sure that we can interoperate well with others. I suppose in some sense, since you're only sending this data over the local unix domain socket it's less of a concern? Thanks, Jake > > Patches 7-9 then add the custom SLAVE_DELAY_TIMING_DATA_NP TLV into > ptp4l, and patch 10 adds it to pmc. > > > Richard Cochran (10): > tlv: Update macro definitions. > tlv: Encode and decode SLAVE_RX_SYNC_TIMING_DATA TLVs. > Introduce a module for slave event monitoring. > clock: Create a slave event monitor. > port: Support slave event monitoring of Sync timing data. > pmc: Show slave receive timing data TLVs attached to signaling > messages. > tlv: Encode and decode SLAVE_DELAY_TIMING_DATA_NP TLVs. > monitor: Add support for slave delay timing data TLV. > port: Support slave event monitoring of delay timing data. > pmc: Show slave delay timing data TLVs attached to signaling messages. > > clock.c| 13 +++ > clock.h| 8 ++ > config.c | 1 + > makefile | 6 +- > monitor.c | 231 > + > monitor.h | 25 ++ > pmc.c | 86 ++ > port.c | 25 +- > port_private.h | 3 + > ptp4l.8| 6 ++ > tlv.c | 163 +- > tlv.h | 67 -- > 12 files changed, 620 insertions(+), 14 deletions(-) > create mode 100644 monitor.c > create mode 100644 monitor.h > > -- > 2.20.1 > > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 00/10] Slave event monitoring
The IEEE 1588 v2.1 standard introduces a new optional feature known as slave event monitoring. This feature defines three new TLVs. 1. SLAVE_RX_SYNC_TIMING_DATA This TLV provides the time stamps T1 and T2 from the message exchange between master and slave. 2. SLAVE_TX_EVENT_TIMESTAMPS This provides the T3 time stamp only. 3. SLAVE_RX_SYNC_COMPUTED_DATA This TLV provides the estimated offset and path delay. The standard leaves the mechanism for enabling and configuring this feature as implementation-defined. This series implements slave monitoring by offering a configuration option that specifies a UDS address, allowing a local client such as the 'pmc' program to monitor the time stamps. While this series implements the first TLV verbatim, the second TLV makes little sense as specified in the standard, because it omits the T4 time stamp. For this reason a custom TLV is used that provides both T3 and T4. The third TLV is not implemented here because it is redundant, merely providing data already available in other management messages. Patches 1-5 implement the SLAVE_RX_SYNC_TIMING_DATA TLV in ptp4l, and patch 6 adds that TLV into pmc. Patches 7-9 then add the custom SLAVE_DELAY_TIMING_DATA_NP TLV into ptp4l, and patch 10 adds it to pmc. Richard Cochran (10): tlv: Update macro definitions. tlv: Encode and decode SLAVE_RX_SYNC_TIMING_DATA TLVs. Introduce a module for slave event monitoring. clock: Create a slave event monitor. port: Support slave event monitoring of Sync timing data. pmc: Show slave receive timing data TLVs attached to signaling messages. tlv: Encode and decode SLAVE_DELAY_TIMING_DATA_NP TLVs. monitor: Add support for slave delay timing data TLV. port: Support slave event monitoring of delay timing data. pmc: Show slave delay timing data TLVs attached to signaling messages. clock.c| 13 +++ clock.h| 8 ++ config.c | 1 + makefile | 6 +- monitor.c | 231 + monitor.h | 25 ++ pmc.c | 86 ++ port.c | 25 +- port_private.h | 3 + ptp4l.8| 6 ++ tlv.c | 163 +- tlv.h | 67 -- 12 files changed, 620 insertions(+), 14 deletions(-) create mode 100644 monitor.c create mode 100644 monitor.h -- 2.20.1 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
