Re: [Linuxptp-devel] [PATCH RFC V1 00/18] NetSync Monitor support
On Tue, Jan 09, 2018 at 05:21:39PM +0100, Miroslav Lichvar wrote: > > I think I said that this works when N==GM. > > Hm, does that change anything? If the delay of event messages going > from GM/N to S is larger than the delay of messages going from S to > GM/N, the clock of S will be running behind GM. The measurements of S > done by the GM/N will have the opposite error. Yes, you are right, of course. I wasn't thinking. The Meinberg doc has this statement: One big advantage of this mechanism is, that the communicated offset and delay from the monitored device can be compared to the measured offset and delay values and - assumed that the monitoring system is perfectly synchronized - asymmetries can be detected. So assuming the asymmetry on the monitor's path is known, then you can measure a constant offset on the normal GM path. Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC V1 00/18] NetSync Monitor support
On Tue, Jan 09, 2018 at 07:52:11AM -0800, Richard Cochran wrote: > On Tue, Jan 09, 2018 at 11:09:43AM +0100, Miroslav Lichvar wrote: > > It's not clear to me how would that work. Let's say I have a > > grandmaster GM, slave S and monitoring node N, and I don't know how > > much asymmetry is there on any of the paths GM-S, GM-N and S-N. How > > will measuring offset of GM and S from N help me? > > I think I said that this works when N==GM. Hm, does that change anything? If the delay of event messages going from GM/N to S is larger than the delay of messages going from S to GM/N, the clock of S will be running behind GM. The measurements of S done by the GM/N will have the opposite error. If there were no other sources of error (e.g. an error specific to boundary clocks, or an asymmetric delay due to the sync message being shorter than the delay request), the offset of S observed by GM/N should be zero. As I understand it, the only way to determine the asymmetry is to directly compare the clocks with a reference clock, e.g. using a PPS signal. -- Miroslav Lichvar -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC V1 00/18] NetSync Monitor support
On Tue, Jan 09, 2018 at 11:09:43AM +0100, Miroslav Lichvar wrote: > It's not clear to me how would that work. Let's say I have a > grandmaster GM, slave S and monitoring node N, and I don't know how > much asymmetry is there on any of the paths GM-S, GM-N and S-N. How > will measuring offset of GM and S from N help me? I think I said that this works when N==GM. > My feeling is that the protocol was not intended for accurate > measurements, but rather for detecting faults and bugs, where the > clocks drift off too much, etc. Yes, that appears to be the most important use case. Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC V1 00/18] NetSync Monitor support
On Mon, Jan 08, 2018 at 09:02:52PM -0800, Richard Cochran wrote: > On Mon, Jan 08, 2018 at 03:56:29PM +0100, Miroslav Lichvar wrote: > > You mean asymmetry added by boundary clocks on the path to the > > grandmaster? > > Yes, or from any other source at all. It's not clear to me how would that work. Let's say I have a grandmaster GM, slave S and monitoring node N, and I don't know how much asymmetry is there on any of the paths GM-S, GM-N and S-N. How will measuring offset of GM and S from N help me? My feeling is that the protocol was not intended for accurate measurements, but rather for detecting faults and bugs, where the clocks drift off too much, etc. > 13.4 Suffix > > An application layer message is suffixed by a contiguous sequence > of zero or more entities of data type TLV ... Nodes should append > no TLV entity to event messages. > > NOTE -- Appending TLV entities to an event message is likely to > change the transmission delay suffered by the messages in passing > through non-PTP bridges. > > Notice it only says "should" and not "must not". So I would say that > TCs must allow TLVs in any message. Ok. If anyone tests this with a TC, I'd be interested to hear if it worked. Thanks, -- Miroslav Lichvar -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC V1 00/18] NetSync Monitor support
On Mon, Jan 08, 2018 at 03:56:29PM +0100, Miroslav Lichvar wrote: > You mean asymmetry added by boundary clocks on the path to the > grandmaster? Yes, or from any other source at all. > One thing I find odd is that the sync message doesn't have a TLV > attached too. Does the specification say anything about that? No, and I noticed that too. The original 1588 standard makes sure that all event messages have the same length, but this extension does break that. I'll mention that to Meinberg, but I think they have already deployed this as is. > Are transparent clocks expected to update the correction field in > messages with TLVs? Good question. 1588 says: 13.2 General message format requirements All messages shall have a header, body, and suffix. The suffix may have zero length. and: 13.4 Suffix An application layer message is suffixed by a contiguous sequence of zero or more entities of data type TLV ... Nodes should append no TLV entity to event messages. NOTE -- Appending TLV entities to an event message is likely to change the transmission delay suffered by the messages in passing through non-PTP bridges. Notice it only says "should" and not "must not". So I would say that TCs must allow TLVs in any message. > This didn't work for me with HW timestamping. I had to modify also > pmc_create() to change the timestamping mode in the transport_open() > call and set the ts_label in the interface struct. Oops, I only tested with SW time stamping. > However, is pmc the right place for this functionality? As the > exchange does not use any management messages, it would probably make > more sense to me if it was in a separate binary, or maybe it could be > a special query mode of ptp4l which would just print the offset and > exit (with the possibility that it could be later used for normal > synchronization of the clock). I put it into pmc because it seemed to be a management function, event though it uses no management messages. If not there, then I prefer a separate binary for this. > There is a hack which detects that pmc is trying to send a message by > checking for POLLOUT in events[1] and nfds == 2. It needs to be > updated if the number of descriptors is increased. (That is even more reason to make NSM its own binary ;) Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC V1 00/18] NetSync Monitor support
On Mon, Jan 01, 2018 at 08:05:31PM -0800, Richard Cochran wrote: > This series adds support for Meinberg Funkuhren's NetSync Monitor > (NSM) protocol. NSM allows a node with a local time reference (like a > GM using GPS) to measure the offset of a given clock. In a nutshell, > NSM works by having the node to be measured act like a unicast master > clock on demand. Very interesting! It looks a bit like an NTP client/server exchange over PTP. > One the nice features of NSM is that, when used from the GM, it allows > one to empirically determine the end to end asymmetry in the network. You mean asymmetry added by boundary clocks on the path to the grandmaster? > The details of the protocol are described in a brief PDF published by > Meinberg. If anyone would like a copy, please contact me off list. One thing I find odd is that the sync message doesn't have a TLV attached too. Does the specification say anything about that? The asymmetric length of the delay request and sync message will make the delay asymmetric in networks with non-TC switches (using store and forward) and add an error to the measured offset (e.g. 16 nanoseconds per switch on 1Gb network). Are transparent clocks expected to update the correction field in messages with TLVs? > Patches 1-3 fix trivial issues found along the way. > Patches 4-9 add various background support bits. > Patches 10-13 implement NSM in the ptp4l program. On first look these all seem good to me. > Patches 14-18 implement monitor support in the pmc program. This didn't work for me with HW timestamping. I had to modify also pmc_create() to change the timestamping mode in the transport_open() call and set the ts_label in the interface struct. With that, it worked as expected. The offset reported by the NSM command between two machines connected directly and synchronized by ptp4l was very close to zero. Nice! However, is pmc the right place for this functionality? As the exchange does not use any management messages, it would probably make more sense to me if it was in a separate binary, or maybe it could be a special query mode of ptp4l which would just print the offset and exit (with the possibility that it could be later used for normal synchronization of the clock). > The last patch breaks linuxptp-testsuite test 20-pmc. The pmc program > exits immediately with no output at all. When I test pmc outside of > the clknetsim it behaves as expected, but I didn't look into why > clknetsim case fails. Maybe you have an idea? There is a hack which detects that pmc is trying to send a message by checking for POLLOUT in events[1] and nfds == 2. It needs to be updated if the number of descriptors is increased. -- Miroslav Lichvar -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH RFC V1 00/18] NetSync Monitor support
This series adds support for Meinberg Funkuhren's NetSync Monitor (NSM) protocol. NSM allows a node with a local time reference (like a GM using GPS) to measure the offset of a given clock. In a nutshell, NSM works by having the node to be measured act like a unicast master clock on demand. 1. The monitoring node sends a unicast delay request with a special TLV attached. 2. The node to be measured replies with a unicast delay response, followed by unicast Sync and FollowUp messages. 3. Once the monitoring node receives the three responses, it calculates the measured node's offset. One the nice features of NSM is that, when used from the GM, it allows one to empirically determine the end to end asymmetry in the network. The details of the protocol are described in a brief PDF published by Meinberg. If anyone would like a copy, please contact me off list. Patches 1-3 fix trivial issues found along the way. Patches 4-9 add various background support bits. Patches 10-13 implement NSM in the ptp4l program. Patches 14-18 implement monitor support in the pmc program. Comments and review are most welcome! Thanks, Richard @Miroslav: The last patch breaks linuxptp-testsuite test 20-pmc. The pmc program exits immediately with no output at all. When I test pmc outside of the clknetsim it behaves as expected, but I didn't look into why clknetsim case fails. Maybe you have an idea? Richard Cochran (18): pmc: Fix white space errors. port: Fix coding style. tlv: Fix coding style. msg: Allow zero length TLVs. msg: Share a static global more globally. msg: Allow tacking a TLV onto a delay request message. clock: Introduce a method to get the current dataset. clock: Introduce a method to obtain the last synchronization time. tmv: Add a method to convert to a struct Timestamp. tlv: Introduce the NetSync Monitor TLVs. port: Introduce unicast sync messages. port: Implement the NetSync Monitor protocol. Add a configuration file option to enable the NetSync Monitor protocol. util: Relocate utility functions from pmc.c. pmc: Add command line options for specifying the time stamping mode. pmc: Add an accessory function for the event message socket. pmc: Introduce a time stamp processor. pmc: Implement the NetSync Monitor query. clock.c | 10 ++ clock.h | 14 +++ config.c | 1 + default.cfg | 1 + gPTP.cfg | 1 + makefile | 11 +- msg.c| 6 +- msg.h| 1 + pmc.c| 101 -- pmc_common.c | 339 ++- pmc_common.h | 21 port.c | 144 +++-- ptp4l.8 | 12 ++- ptp4l.c | 2 - tlv.c| 147 +- tlv.h| 17 +++ tmv.h| 15 +++ util.c | 39 +++ util.h | 15 +++ 19 files changed, 816 insertions(+), 81 deletions(-) -- 2.11.0 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
