WeOSPTP HowTo
This document, being a non-exhaustive guide, outlines some practical examples of how to configure and use Precision Time Protocol.
For an overview of what PTP is and how it may be configured, refer to:
Introduction
PTP may be used in various networks of different structures and complexity levels. One of the reasons behind flexibility and scalability of this protocol lies in the concept of Transparent Clock (TC). While Ordinary Clock (OC) has more or less static configuration and function, acting as either Master (providing time) or Slave (receiving time), TC acts as a kind of port expander, as in Figure 1 below, allowing numerous Slave clocks to get synchronized to single time source, the so called Grand Master clock (GM). There may be many interconnected TCs in a network, each serving as a link to time source, and also, in the case of ring structure, providing failover function. The workflow of each TC may dynamically change over time, adapting to various cicrumstances and states occuring in the network.
.-------.
| |
+----------+s OC |
| | |
| '---+---'
.-------. .---+---. .-------.
| | | m | | |
| GM m+-------+s TC m+------+s OC |
| | | m | | |
'-------' '---+---' '---+---'
| .-------.
| | |
+----------+s OC |
| |
'-------'
Figure 1: Transparent clock as port expander. Letters 'm' and 's' represent MASTER and SLAVE ports respectively.
General considerations
PTP could be used in two different ways: within a vlan, or outside any vlan.
If PTP is used in a vlan, make sure to add PTP ports to desired vlan. Suppose ports eth3 and eth4 are standalone interfaces, and PTP is supposed to run in vlan 100:
oc-gm:/#> conf vlan 100 oc-gm:/config/vlan-100/#> untagged eth3,eth4 oc-gm:/config/vlan-100/#> leave oc-gm:/#>
If PTP is used outside any vlan, make sure to remove PTP ports from vlans and have them as standalone interfaces in WeOS. Suppose ports eth3 and eth4 are part of vlan 1:
oc-gm:/#> conf vlan 1 oc-gm:/config/vlan-1/#> no untagged eth3,eth4 oc-gm:/config/vlan-1/#> leave oc-gm:/#>
Regardless of chosen configuration, consistency should be kept in all ptp devices.
PTP configuration for a network represented in Figure 1
To ensure correct operation of PTP, all devices should use the same profile.
Let us configure GM. This is done by configuring our device as an OC and giving it high priority, by setting priority1 attribute to low value. In our little network, clock with highest priority will be automatically selected by BMCA as GM. Note that only one port may be selected for an OC.
oc-gm:/#> conf ptp oc-gm:/config/ptp/#> enable oc-gm:/config/ptp/#> description name "GM" location "howto" oc-gm:/config/ptp/#> clock ordinary oc-gm:/config/ptp/clock-ordinary/#> ports eth4 oc-gm:/config/ptp/clock-ordinary/#> priority1 100 oc-gm:/config/ptp/clock-ordinary/#> end oc-gm:/config/ptp/#> profile power-v2 oc-gm:/config/ptp/profile-power-v2/#> leave oc-gm:/#>
Our network is composed of 5 devices, out of which one device is our TC. Let us add 4 ports by which our TC is connected to other devices in the network. Note that setting of description attribute is not mandatory but will aid us in debugging and monitoring PTP network later on.
tc:/config/#> ptp tc:/config/ptp#> enable tc:/config/ptp#> description name "TC" location "howto" tc:/config/ptp#> profile power-v2 tc:/config/ptp/profile-power-v2/#> end tc:/config/ptp#> clock transparent tc:/config/ptp/clock-transparent/#> ports eth5 eth9..eth11 tc:/config/ptp/clock-transparent/#> end tc:/config/ptp#> leave
Slave devices are configured as OCs, with their priority1 attribute left untouched. Note that all OC Slave devices will have identical configuration, with the sole exception of port attribute, which may differ from device to device.
oc-slave:/config/#> ptp oc-slave:/config/ptp#> enable oc-slave:/config/ptp#> description name "slave1" location "howto" oc-slave:/config/ptp/#> clock ordinary oc-slave:/config/ptp/clock-ordinary/#> ports eth4 oc-slave:/config/ptp/clock-ordinary/#> end oc-slave:/config/ptp#> profile power-v2 oc-slave:/config/ptp/profile-power-v2/#>#> leave
NOTE: Only TC has official support in WeOS. OC may be used only for testing purposes.
Monitoring Status
Now that we have configured our PTP network, we want to know whether it is functioning as expected. We expect to see three slave devices, each synchronized to the GM.
Monitoring of PTP network is possible from any device in the network, by by issuing simple queries from adminexec. Let us issue the following queries from our TC:
show ptp command, see Listing 1, shows current configuration of our device
as well as PTP states for each port. We may observe that all ports of our TC
are operational, i.e, in MASTER or UNCALIBRATED state and peer delay for each
link has been calculated.
show ptp network command may be used to monitor our PTP network, see Listing 2.
We observe that in our case slave clocks 00077c.fffe.784fda, 00077c.fffe.78530b
and 00077c.fffe.7bf4c5 are closely synchronized to the grandmaster clock as they
are within the offset of 7.0, 2.0 and 0.0 nanoseconds respectively.
show ptp ID : 00077c.fffe.785325 Type : TC P2P Domain : 0 Mean Path delay : 0.0 Master Offset : -669033273898.0 Priority1 : 254 Priority2 : 128 Product : Westermo;RedFox-5728-E-F16G-T12G-HVHV;00:07:7c:78:53:20 Distance : 1 Description : TC Ports ID INTERFACE STATE PEER DELAY 00077c.fffe.785325-1 eth9 MASTER 88 00077c.fffe.785325-2 eth10 UNCALIBRATED 94 00077c.fffe.785325-3 eth11 MASTER 11
Listing 1: Transparent clock status.
tc:/#> show ptp network
Clocks
ID TYPE DOMAIN MASTER OFFSET DESCRIPTION
00077c.fffe.785325 TC P2P 0 -669033063522.0 TC
00077c.fffe.784fda OC 0 7.0 slave1
00077c.fffe.78530b OC 0 2.0 slave2
00077c.fffe.7bf4c5 OC 0 0.0 slave3
Listing 2: PTP network status. Collected from Transparent clock.