Add a New PTP Source
TimeKeeper on VelaSync can be deployed as an IEEE 1588 PTP Grandmaster and communicate with almost any PTP boundary clock and PTP client on the market, regardless whether it is a hardware appliance, a software instance, or a PTP-aware networking component.
TimeKeeper can serve IEEE 1588, Versions 1 and 2, in a number of ways. It can serve multiple domains via multiple interfaces, allowing traffic to be matched properly with the network. This avoids the introduction of link asymmetries that can cause clients to be unintentionally biased.
Key features of TimeKeeper running on VelaSync as a PTP Grandmaster include:
- Support for the Default, Telecom, and Hybrid PTP profiles
- Serves via many domains on many interfaces for link redundancy and managed PTP distribution
- Supports standard and extended management formats to collect client and Grandmaster information in one centralized location
- Can act solely as a management node on the network, collecting and analyzing timing data of discovered clients and Grandmasters.
The PTP Synchronization Mode VelaSync with TimeKeeper installed uses for the event messages it sends out is 2-Step Mode. TimeKeeper is, however, capable of syncing to other 1-Step Mode PTP servers e.g., the PTP Option Card, Model -32, as used in Spectracom SecureSync servers.
PTP is very reliant on Multicast traffic, particularly in the default profile. In this mode, time is distributed from the Grandmaster via Multicast, and every client that requests information from the Grandmaster communicates via Multicast. Since every client will see every other client's Grandmaster request, a lot of network and processor bandwidth will be consumed, which will likely cause problems in large networks (which may have thousands of nodes).
A hybrid mode helps to avoid creating extra Multicast traffic by allowing for the Grandmaster to distribute time via multicast to its clients, while the clients that need data from the Grandmaster (e.g., delay information) make direct Unicast queries.
Another option is full Unicast – also known as the Telecom profile. In this case, the client subscribes to unicast updates from the Grandmaster, and also exchanges all other information from the Grandmaster over a unicast connection. This can be ideal for longer links where multicast traffic is not an option.
Note that—contrary to NTP, where you just check the box Serve NTP under the TimeKeeper Configuration subtab—PTP requires you to configure each interface separately. This ensures e.g., that PTP for a 10 Gb network is being specifically delivered on a 10 Gb link. It also provides redundancy and a failover option for clients.
To change the configuration of an existing PTP source, or create a new PTP source:
- Navigate to Configuration > TimeKeeper configuration, and under the Sources tab, select the PTP source you would like to edit, or select Add a new source below.
Editing an existing NTP source
The editable features are:
PTP server (telecom profile/full unicast)
IP address or domain name of the PTP server to request a unicast lease from. If you enter an IP address or server name, TimeKeeper assumes your intent is to use Unicast. If you leave the field blank, TimeKeeper will use PTP multicast.
The numeric domain that TimeKeeper will watch for PTP data on.
Sync error threshold
If the sync quality (offset) exceeds this floating point value, emit trap/syslog messages.
[Choose one: SOURCE0, 1, 2, etc.] Combine this source's second-scale time with time of day information from the source named here. [Default: unselect/Choose one]
Designate a low quality source
Assume source is very low quality and prioritize minimal changes to local oscillator to stabilize time.
Bias the clock to account for cable delays or asymmetries. With a long cable run that delays signal by 1ms, use a value of 0.001. TimeKeeper will subtract this value from the incoming timing signal.
PTP client version
Version 1 refers to IEEE 1588-2002, and the preferred Version 2 refers to IEEE 1588-2008.
Unicast delay requests
If checked, unicast delay requests back to the server will be enabled.
This source should watch the named interface for PTP data. The interface name has to correspond with a valid Linux network device name.
Use transparent clock corrections
If disabled, this source will not make use of any transparent clock information provided in the PTP data, otherwise it will apply the correction to the timing data.
Permit lost but promised followups
If disabled, a PTP grandmaster that promises a followup message must deliver one in order for this source to use a given time update.
If enabled, a failed followup delivery will not prevent the sample from being updated.
The default (= disabled) is recommended in nearly all deployments, as missing followups indicate a problem with PTP delivery or the grandmaster.
Detect asymmetry – only enable if properly configured
Enable to detect and measure network link asymmetry. Your network needs to be properly configured to test for asymmetries. For more information, see Detecting Network Asymmetries.
Note: Do not forget to click Save TimeKeeper changes in the upper right corner, once you have applied your changes.
Additional information about adding sources can be found under Configuring Timing Sources.