This recipe will provide a step-by-step guide to setting up a resilient timing network using Timebeat software. The goal of this process will be that at the end of which you can create your own resilient PTP timing network with the steps learned in this and tailor them to your needs.
Problem:
You want to be able to synchronise end devices using PTP but with built-in resiliency to account for failure or loss of PTP input.
Ingredients (the minimum required items)
- A minimum of 2 PTP Grandmasters
- A device operating as a PTP slave
- A Local Area Network
- Completed the recipe for setting up a simple PTP timing network
Total Prep time: 15 mins, Total Cook time: 15 mins
In this recipe, we will use 2 grandmasters running Timebeat software and the assumption has been made that we have completed the recipe for setting up a simple PTP network. This recipe can be found here.
An assumption has also been made that the grandmaster has already been configured to receive UTC. a guide for this can be found within the recipe linked above or a standalone guide here.
Step 1:
First, we are going to need to set up our second grandmaster. For this follow the steps learned in the "simple PTP network" recipe so that our starting point is the Timebeat config file on the grandmaster.
Within the config file, we have two options ahead of us. Configure a unique PTP feed so that we are not utilising the functionality of the "Best master clock algorithm" (BMCA) or we can configure an identical PTP feed and take advantage of BMCA.
In this example (and typically what we recommend), we will set up a completely unique PTP feed to take advantage of Timebeat's intelligent source selection in place of the more dated BMCA configuration.
So in the config file, we will amend the following items
line 29: we will amend to have domain 10 (this is different from our original grandmaster which was set to domain 0)
line 32 & 33: we just uncomment so that they become active config lines.
line 44: we want this to be the interface that will distribute PTP, in our case as it is an identical device as the other guide it remains the same with ens1.
27 # PTP Config example
28 - protocol: ptp
29 domain: 10
30 #serve_unicast: true
31 #max_unicast_subscribers: 0
32 serve_multicast: true
33 server_only: true
34 announce_interval: 1
35 sync_interval: 0
36 delayrequest_interval: 0
37 #unicast_master_table: ['1.2.3.4','2.3.4.5', '3.4.5.6']
38 #delay_strategy: e2e # other options which can be used are: 'p2p'
39 #hybrid_e2e: false # Send delay requests as unicast (enterprise profile)
40 #priority1: 128
41 #priority2: 128
42 #monitor_only: false
43 #use_layer2: false # Use ptp over ethernet instead of IP/UDP
44 interface: ens1
45 #profile: 'G.8275.2' # other options which can be used are: 'G.8275.1', 'G.8265.1' and 'enterprise-draft'
46 #logsource: 'Grandmaster Clock in NY4' # configurable name for source included in all logging records for source
47 #asymmetry_compensation: 0 # In nanoseconds. Static compensation for know asymmetry (+/- as the case maybe)
48 #max_packets_per_second: 0 # If inbound packet rate exceeds this a WRED algorithm is used
Once complete just save the config and quit. (if using vi the below command will do the trick).
:wq!
Step 2:
Now we start the service using the standard commands
LINUX:
root@gm02 ~]# systemctl start timebeat
WINDOWS:
The easiest method in Windows is to open up the Task Manager, select Processes, find Timebeat in the list, right-click and select start.
Step 3:
Now that we have PTP leaving 2 grandmasters we have to configure our end device to receive both PTP feeds. We will use the same device as in the previous recipe as this already has our first grandmaster configured.
Config for Grandmaster 1 on end device:
27 # PTP Config example
28 - protocol: ptp
29 domain: 0
30 #serve_unicast: true
31 #max_unicast_subscribers: 0
32 #serve_multicast: true
33 #server_only: true
34 announce_interval: 1
35 sync_interval: 0
36 delayrequest_interval: 0
37 #unicast_master_table: ['1.2.3.4','2.3.4.5', '3.4.5.6']
38 #delay_strategy: e2e # other options which can be used are: 'p2p'
39 #hybrid_e2e: false # Send delay requests as unicast (enterprise profile)
40 #priority1: 128
41 #priority2: 128
42 #monitor_only: false
43 #use_layer2: false # Use ptp over ethernet instead of IP/UDP
44 interface: ens1
45 #profile: 'G.8275.2' # other options which can be used are: 'G.8275.1', 'G.8265.1' and 'enterprise-draft'
46 #logsource: 'Grandmaster Clock in NY4' # configurable name for source included in all logging records for source
47 #asymmetry_compensation: 0 # In nanoseconds. Static compensation for know asymmetry (+/- as the case maybe)
48 #max_packets_per_second: 0 # If inbound packet rate exceeds this a WRED algorithm is used
So as you recall we have this configured as our "primary source". Timebeat can be configured in several ways as it relates to how it treats a source. If we configure our second source of PTP to also be a "primary source" Timebeat will synchronise to the median time source. With only 2 sources this means that it will create an arithmetic mean of the two sources and synchronise to that, If we had 3 sources it would utilise the median.
In this recipe however we will configure our second source as a "secondary source", this means that it will be constantly monitored but only used to synchronise against if our primary source is unavailable. A traditional view on redundant failover configuration.
In the secondary source section, we configure our PTP source, so it will look like the one below in this case.
94 # PTP Config example
95 - protocol: ptp
96 domain: 10
97 #serve_unicast: true
98 #max_unicast_subscribers: 0
99 #serve_multicast: true
100 #server_only: true
101 announce_interval: 1
102 sync_interval: 0
103 delayrequest_interval: 0
104 #unicast_master_table: ['1.2.3.4','2.3.4.5', '3.4.5.6']
105 #delay_strategy: e2e # other options which can be used are: 'p2p'
106 #hybrid_e2e: false # Send delay requests as unicast (enterprise profile)
107 #priority1: 128
108 #priority2: 128
109 #monitor_only: false
110 #use_layer2: false # Use ptp over ethernet instead of IP/UDP
111 interface: ens1
112 #profile: 'G.8275.2' # other options which can be used are: 'G.8275.1', 'G.8265.1' and 'enterprise-draft'
113 #logsource: 'Grandmaster Clock in NY4' # configurable name for source included in all logging records for source
114 #asymmetry_compensation: 0 # In nanoseconds. Static compensation for know asymmetry (+/- as the case maybe)
115 #max_packets_per_second: 0 # If inbound packet rate exceeds this a WRED algorithm is used
So you can see we amend line 96 and line 111, whereas all we do on lines 95, 101, 102 & 103 is uncomment them.
Once complete just save the config and quit. (if using vi the below command will do the trick).
:wq!
Step 4:
Now we start the service using the standard commands
LINUX:
root@fedora ~]# systemctl start timebeat
WINDOWS:
The easiest method in Windows is to open up the Task Manager, select Processes, find Timebeat in the list, right-click and select start.
Step 5:
And that is all there is to it. Now we just check out our handy work in the front end where we will see our device report 2 PTP time sources against our server. For this we check out the "Device information" dashboard and scroll down to Time Source.