Measuring and Monitoring Options
Heiko Gerstung <heiko.gerstung@meinberg.de>
for Time Sync Infrastructures
OCP-TAP Project
SyncMon
Reverse PTP
Live Demo
Measuring Timing Signals
SyncMon
SyncMon allows to measure and collect timing signals including network protocols for synchronization (NTP and PTP).
It can also collect other statistics like CPU utilization or memory consumption or the data of various temperature sensors.
How does it work?
SyncMon
Depending on the available hardware (modules) and software (firmware revisions/features), a large number of sensors („monitoring nodes“) can be queried.
For timing signals, offset measurements are taken by the hardware and collected on a local storage.
For most sensors, limits can be defined which trigger automatic alarm notifications.
Time Measurements
SyncMon
The measurements of external time sync signals (or network time protocols) are taken against the own hardware clock of the system.
How that hardware clock is synchronized, is independent from the measurement process. The clock could be synchronized by GNSS, an incoming PPS, PTP or it could just be freewheeling.
For PTP measurements, you typically want to compare that against a common reference like GNSS.
Combining Measurements
SyncMon
It is possible to compare two or more nodes to find out if there are any shared patterns or correlated events.
This includes multiple sync signals / inputs of the same type and also completely different measurements, e.g. temperature and PPS and number of received satellites.
One use case is to measure the PPS of a PTP synchronized device and compare it with the reported PTP offset (and the GM‘s PPS as well)
SyncMon
Monitoring timing related objects:�- NTP and PTP�- GNSS monitoring�- PPS/IRIG/…�- system status (CPU, RAM, …)
Reverse PTP
Live Demo
PTP Upside Down
Reverse PTP
Measuring PTP nodes with SyncMon is supported in a number of different ways. The most used one is the „Reverse PTP“ approach, which uses standard PTP message formats in a „reverse“ way.
This allows to measure the offset of a remote �device and avoids relying exclusively on the�self-reported state.
Basic Protocol Concept
Reverse PTP
From the start, the reverse PTP approach was designed to run real measurements and not rely on each PTP device/instance to just forward self reported state and time error estimation.
The basic concept works like this:
This provides all four required timestamps t1,t2,t3,t4 to the monitoring node as well as state information.
Measurements
Reverse PTP
After receiving the Delay Response and Sync messages, the monitoring device has all four timestamps and can calculate the offset and path delay.
Since this is a roundtrip measurement, any asymmetries are not easy to detect and all PDV effects and jitter on the network path to the measured device are affecting the measurement just like they affect the synchronization itself.
There are, however, options to work around this and detect asymmetries and PDV.
Monitoring PTP State
Reverse PTP
The Reverse PTP protocol also defines a number of TLVs which the monitored device can add to its response, allowing the Syncmon instance to record state changes and raise alarms if required.
This and some other extended values can be recorded and shown in diagrams when a PTP card is set up as a standard PTP node instead of a Reverse PTP Monitoring node.
The next revision of SyncMon will make more use of the TLV based state information.
Conceptual Benefits
Reverse PTP
By using unicast communication, a monitoring node can directly access a PTP device, even if it is „behind“ one or more boundary clocks.
The monitoring node can either be running on the grandmaster clock(s) itself or on a completely separate and independent system. If a different network path is used, asymmetries could be detected as well.
The monitoring node could use a different set of reference sources for time (e.g. different GNSS constellation) to spot changes in the GM reference source.
The concept supports running multiple monitoring nodes for the sake of redundancy.
TLVs
Reverse PTP
The NetSync Monitor (Reverse PTP) rev6 spec defines a number of TLVs. Those TLVs are using organization extension TLVs with the organizationId 0xEC4670 (Meinberg‘s OUI).
The request TLVs (PTPMON_REQ_TLV and the optional MTIE_REQ_TLV) must be attached to the DELAY_REQ message sent by the monitoring node to a remote PTP device.
The device then answers and attaches the PTPMON_RESP_TLV and, if required and supported, the MTIE_RESP_TLV.
Alternative PTP Monitoring
Reverse PTP
The described Reverse PTP Protocol required dedicated support in a PTP device. In order to allow to monitor PTP devices without this feature, SyncMon allows two alternative ways of monitoring PTP devices or services in a network.
Alternative A: Using PTP Management Messages as standardized in IEEE 1588
Alternative B: Using dedicated PTP modules in the monitoring system that acts as a OC. By connecting those modules to different network segments, it is possible to monitor the health of PTP at each of those network locations.
3rd Party Support
Reverse PTP
The Reverse PTP Technology is supported by the Oregano PTP stack, which is used on all Meinberg PTP cards and is the core of the Meinberg PTP client software for Linux and Windows.
A number of 3rd party software stacks support this protocol as well, for example linuxptp (net_sync_monitor option).
SyncMon
Monitoring timing related objects:�- NTP and PTP�- GNSS monitoring�- PPS/IRIG/…�- system status (CPU, RAM, …)
Reverse PTP
Live Demo
Let‘s have a look
Now open your browser, Heiko…
Thank you for your attention!��Questions?�heiko.gerstung@meinberg.de��LinkedIn: heikogerstung�https://www.linkedin.com/in/heikogerstung��Twitter: @hgerstung��Website: https://www.meinbergglobal.com��