This is a draft document that was built and uploaded automatically. It may document beta software and be incomplete or even incorrect. Use this document at your own risk.

Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
SUSE Telco Cloud Documentation|Telco features configuration|Precision Time Protocol

46 Precision Time Protocol

Precision Time Protocol (PTP) is a network protocol developed by the Institute of Electrical and Electronics Engineers (IEEE) to enable sub-microsecond time synchronization in a computer network. Since its inception and for a couple of decades now, PTP has been in use in many industries. It has recently seen a growing adoption in the telecommunication networks as a vital element to 5G networks. While being a relatively simple protocol, its configuration can change significantly depending on the application. For this reason, multiple profiles have been defined and standardized.

In this section, only telco-specific profiles will be covered. Consequently time-stamping capability and a PTP hardware clock (PHC) in the NIC will be assumed. Nowadays, all telco-grade network adapters come with PTP support in hardware, but you can verify such capabilities with the following command:

# ethtool -T p1p1
Time stamping parameters for p1p1:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        all

Replace p1p1 with name of the interface to be used for PTP.

The following sections will provide guidance on how to install and configure PTP on SUSE Telco Cloud specifically, but familiarity with basic PTP concepts is expected. For a brief overview of PTP and the implementation included in SUSE Telco Cloud, refer to the SLES Precision Time Protocol documentation.

46.1 Install PTP software components

In SUSE Telco Cloud, the PTP implementation is provided by the linuxptp package, which includes two components:

  • ptp4l: a daemon that controls the PHC on the NIC and runs the PTP protocol

  • phc2sys: a daemon that keeps the system clock in sync with the PTP-synchronized PHC on the NIC

Both daemons are required for the system synchronization to fully work and must be correctly configured according to your setup. This is covered in Section 46.2, “Configure PTP for telco deployments”.

The easiest and best way to integrate PTP in your downstream cluster is to add the linuxptp package under packageList in the Edge Image Builder (EIB) definition file. This way the PTP control plane software will be installed automatically during the cluster provisioning. See the EIB documentation (Section 5.3.6, “Configuring RPM packages”) for more information on installing packages.

Below find a sample EIB manifest with linuxptp:

apiVersion: 1.3
image:
  imageType: RAW
  arch: x86_64
  baseImage: SL-Micro.x86_64-6.2-Base-RT-GM.raw
  outputImageName: eibimage-slmicrort-telco.raw
operatingSystem:
  time:
    timezone: America/New_York
  kernelArgs:
    - ignition.platform.id=openstack
  systemd:
    disable:
      - rebootmgr
      - transactional-update.timer
      - transactional-update-cleanup.timer
      - fstrim
      - time-sync.target
    enable:
      - ptp4l
      - phc2sys
  users:
    - username: root
      encryptedPassword: $ROOT_PASSWORD
  packages:
    packageList:
      - jq            # Non Telco specific - category: testing/utils
      - dpdk          # TelCo Core-Network UserPlane (5G UPF) and RAN UserPlane (gNB: DU and CU-UP) - category: runtime
      - dpdk-tools    # TelCo Core-Network UserPlane (5G UPF) and RAN UserPlane (gNB: DU and CU-UP) - category: testing/utils
      - libdpdk-25    # TelCo Core-Network UserPlane (5G UPF) and RAN UserPlane (gNB: DU and CU-UP) - category: runtime
      - pf-bb-config  # TelCo RAN (gNB: DU) - category: config.
      - open-iscsi    # Non Telco specific (required by SUSE Storage/Longhorn) - category: runtime
      - tuned         # Non Telco specific (linux tuning) - category: config.
      - cpupower      # Non Telco specific (linux tuning - CPU power related settings) - category: config.
      - rt-tests      # Non Telco specific (RT scheduler-latency testing) - category: testing/utils
      - linuxptp      # TelCo RAN; time sync (gNB: DU) - category: runtime
      - synce4l       # TelCo RAN; time sync (gNN: DU) - category: runtime
      - pciutils      # Non Telco specific (provides "lspci" command) - category: testing/utils
      - numactl       # Non Telco specific (provides "numatcl" command) - category: testing/utils
    sccRegistrationCode: $SCC_REGISTRATION_CODE
Note
Note

The linuxptp package included in SUSE Telco Cloud does not enable ptp4l and phc2sys by default. If their system-specific configuration files are deployed at provisioning time (see Section 46.3, “Cluster API integration”), they should be enabled. Do so by adding them to the systemd section of the manifest, as in the example above.

Follow the usual process to build the image as described in the EIB Documentation (Section 5.4, “Building the image”) and use it to deploy your cluster. If you are new to EIB, start from Chapter 12, Edge Image Builder instead.

46.2 Configure PTP for telco deployments

Many telco applications require strict phase and time synchronization with little deviance, which resulted in a definition of two telco-oriented profiles: the ITU-T G.8275.1 and ITU-T G.8275.2. They both have a high rate of sync messages and other distinctive traits, such as the use of an alternative Best Master Clock Algorithm (BMCA). Such behavior mandates specific settings in the configuration file consumed by ptp4l, provided in the following sections as a reference.

Note
Note
  • Both sections only cover the case of an ordinary clock in Time Receiver configuration.

  • Any such profile must be used in a well-planned PTP infrastructure.

  • Your specific PTP network may require additional configuration tuning, make sure to review and adapt the provided examples if needed.

46.2.1 PTP profile ITU-T G.8275.1

The G.8275.1 profile has the following specifics:

  • Runs directly on Ethernet and requires full network support (adjacent nodes/switches must support PTP).

  • The default domain setting is 24.

  • Dataset comparison is based on the G.8275.x algorithm and its localPriority values after priority2.

Copy the following content to a file named /etc/ptp4l-G.8275.1.conf:

# Telecom G.8275.1 example configuration
[global]
domainNumber                    24
priority2			255
dataset_comparison              G.8275.x
G.8275.portDS.localPriority     128
G.8275.defaultDS.localPriority  128
maxStepsRemoved                 255
logAnnounceInterval             -3
logSyncInterval                 -4
logMinDelayReqInterval          -4
announceReceiptTimeout		3
serverOnly                      0
ptp_dst_mac                     01:80:C2:00:00:0E
network_transport               L2

Once the file has been created, it must be referenced in /etc/sysconfig/ptp4l for the daemon to start correctly. This can be done by changing the OPTIONS= line to:

OPTIONS="-f /etc/ptp4l-G.8275.1.conf -i $IFNAME --message_tag ptp-8275.1"

More precisely:

  • -f requires the file name of the configuration file to use; /etc/ptp4l-G.8275.1.conf in this case

  • -i requires the name of the interface to use, replace $IFNAME with a real interface name.

  • --message_tag allows to better identify the ptp4l output in the system logs and is optional.

Once the steps above are complete, the ptp4l daemon must be (re)started:

# systemctl restart ptp4l

Check the synchronization status by observing the logs with:

# journalctl -e -u ptp4l

46.2.2 PTP profile ITU-T G.8275.2

The G.8275.2 profile has the following specifics:

  • Runs on IP and does not require full network support (adjacent nodes/switches may not support PTP).

  • The default domain setting is 44.

  • Dataset comparison is based on the G.8275.x algorithm and its localPriority values after priority2.

Copy the following content to a file named /etc/ptp4l-G.8275.2.conf:

# Telecom G.8275.2 example configuration
[global]
domainNumber                    44
priority2			255
dataset_comparison              G.8275.x
G.8275.portDS.localPriority     128
G.8275.defaultDS.localPriority  128
maxStepsRemoved                 255
logAnnounceInterval             0
serverOnly                      0
hybrid_e2e                      1
inhibit_multicast_service       1
unicast_listen                  1
unicast_req_duration            60
logSyncInterval                 -5
logMinDelayReqInterval          -4
announceReceiptTimeout		2
#
# Customize the following for slave operation:
#
[unicast_master_table]
table_id                        1
logQueryInterval                2
UDPv4                           $PEER_IP_ADDRESS
[$IFNAME]
unicast_master_table            1

Make sure to replace the following placeholders:

  • $PEER_IP_ADDRESS - the IP address of the next PTP node to communicate with, such as the master or boundary clock that will provide synchronization.

  • $IFNAME - tells ptp4l what interface to use for PTP.

Once the file has been created, it must be referenced, along with the name of the interface to use for PTP, in /etc/sysconfig/ptp4l for the daemon to start correctly. This can be done by changing the OPTIONS= line to:

OPTIONS="-f /etc/ptp4l-G.8275.2.conf --message_tag ptp-8275.2"

More precisely:

  • -f requires the file name of the configuration file to use. In this case, it is /etc/ptp4l-G.8275.2.conf.

  • --message_tag allows to better identify the ptp4l output in the system logs and is optional.

Once the steps above are complete, the ptp4l daemon must be (re)started:

# systemctl restart ptp4l

Check the synchronization status by observing the logs with:

# journalctl -e -u ptp4l

46.2.3 PTP configuration of a Boundary Clock

The previous sections covered the configuration of an Ordinary Clock, but Telco deployments can require the node to act as a Boundary Clock. In such a scenario the reference time must be propagated from a Grand Master to one or more Time Receivers downstream, which requires an NIC with two or more ports. In this case one port will take the Time Receiver role, that is driving the updates of the PTP Hardware Clock (PHC) on the NIC, while the remaining ones will work as Time Transmitters. A single instance of ptp4l is sufficient for a single multi-port NIC, but each kernel interface involved in the time distribution must be provided, as part of its configuration. For example, update the /etc/sysconfig/ptp4l file to include four ports, just replace the variables with actual interface names or adjust it as needed:

OPTIONS="-f /etc/ptp4l-G.8275.1.conf --message_tag ptp-8275.1 -i $IFNAME1 -i $IFNAME2 -i $IFNAME3 -i $IFNAME4"
Note
Note

There is no need to set clock_type to BC, as it will be automatically implied if more than one port is provided.

Once done, the ptp4l daemon can be (re)started, with:

# systemctl restart ptp4l

Without any specific port configuration, ptp4l will run the BMCA to determine through which port the GM can be reached. If a static configuration is preferred, append a section for each port with the prescribed role in the configuration file. For example:

# Telecom G.8275.1 example configuration
[global]
domainNumber                    24
priority2                       255
dataset_comparison              G.8275.x
G.8275.portDS.localPriority     128
G.8275.defaultDS.localPriority  128
maxStepsRemoved                 255
logAnnounceInterval             -3
logSyncInterval                 -4
logMinDelayReqInterval          -4
announceReceiptTimeout          3
ptp_dst_mac                     01:80:C2:00:00:0E
network_transport               L2

[$IFNAME1]
# Time Receiver by default

[$IFNAME2]
serverOnly                      1

[$IFNAME3]
serverOnly                      1

[$IFNAME4]
serverOnly                      1

However, make sure to determine the correct connection to the GM before starting the daemon.

46.2.4 Synchronization of the system clock from PTP

It is important to keep in mind that PTP works by synchronizing NIC local hardware clocks. This does not automatically align the system clock with the GM, as the system clock is derived from a different hardware clock. In order to keep the system clock in sync with PTP, phc2sys must be run. It is recommended that you fully complete the configuration of ptp4l before moving to phc2sys. phc2sys does not require a configuration file by default and its execution parameters can be solely controlled through the OPTIONS= variable present in /etc/sysconfig/ptp4l, in a similar fashion to ptp4l:

OPTIONS="-s $IFNAME -w"

Where $IFNAME is the name of the interface already set up in ptp4l that will be used as the source for the system clock. This is used to identify the source PHC.

However, if a specific PTP profile or domain number is used, phc2sys might require to be provided with a configuration file in accordance with the one provided to ptp4l. In most cases it can also be directly reused with phc2sys:

OPTIONS="-f /etc/ptp4l-G.8275.1.conf -s $IFNAME -w"

46.3 Cluster API integration

Whenever a cluster is deployed through a management cluster and directed network provisioning, both the configuration file and the two configuration variables in /etc/sysconfig can be deployed on the host at provisioning time. Below is an excerpt from a cluster definition, focusing on a modified RKE2ControlPlane object that deploys the same G.8275.1 configuration file on all hosts:

apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: RKE2ControlPlane
metadata:
  name: single-node-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
    kind: Metal3MachineTemplate
    name: single-node-cluster-controlplane
  replicas: 1
  version: ${RKE2_VERSION}
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  registrationMethod: "control-plane-endpoint"
  serverConfig:
    cni: canal
  agentConfig:
    format: ignition
    cisProfile: cis
    additionalUserData:
      config: |
        variant: fcos
        version: 1.4.0
        systemd:
          units:
            - name: rke2-preinstall.service
              enabled: true
              contents: |
                [Unit]
                Description=rke2-preinstall
                Wants=network-online.target
                Before=rke2-install.service
                ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
                [Service]
                Type=oneshot
                User=root
                ExecStartPre=/bin/sh -c "mount -L config-2 /mnt"
                ExecStart=/bin/sh -c "sed -i \"s/BAREMETALHOST_UUID/$(jq -r .uuid /mnt/openstack/latest/meta_data.json)/\" /etc/rancher/rke2/config.yaml"
                ExecStart=/bin/sh -c "echo \"node-name: $(jq -r .name /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
                ExecStartPost=/bin/sh -c "umount /mnt"
                [Install]
                WantedBy=multi-user.target
        storage:
          files:
            - path: /etc/ptp4l-G.8275.1.conf
              overwrite: true
              contents:
                inline: |
                  # Telecom G.8275.1 example configuration
                  [global]
                  domainNumber                    24
                  priority2                       255
                  dataset_comparison              G.8275.x
                  G.8275.portDS.localPriority     128
                  G.8275.defaultDS.localPriority  128
                  maxStepsRemoved                 255
                  logAnnounceInterval             -3
                  logSyncInterval                 -4
                  logMinDelayReqInterval          -4
                  announceReceiptTimeout          3
                  serverOnly                      0
                  ptp_dst_mac                     01:80:C2:00:00:0E
                  network_transport               L2
              mode: 0644
              user:
                name: root
              group:
                name: root
            - path: /etc/sysconfig/ptp4l
              overwrite: true
              contents:
                inline: |
                  ## Path:           Network/LinuxPTP
                  ## Description:    Precision Time Protocol (PTP): ptp4l settings
                  ## Type:           string
                  ## Default:        "-i eth0 -f /etc/ptp4l.conf"
                  ## ServiceRestart: ptp4l
                  #
                  # Arguments when starting ptp4l(8).
                  #
                  OPTIONS="-f /etc/ptp4l-G.8275.1.conf -i $IFNAME --message_tag ptp-8275.1"
              mode: 0644
              user:
                name: root
              group:
                name: root
            - path: /etc/sysconfig/phc2sys
              overwrite: true
              contents:
                inline: |
                  ## Path:           Network/LinuxPTP
                  ## Description:    Precision Time Protocol (PTP): phc2sys settings
                  ## Type:           string
                  ## Default:        "-s eth0 -w"
                  ## ServiceRestart: phc2sys
                  #
                  # Arguments when starting phc2sys(8).
                  #
                  OPTIONS="-s $IFNAME -w"
              mode: 0644
              user:
                name: root
              group:
                name: root
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    nodeName: "localhost.localdomain"

Besides other variables, the above definition must be completed with the interface name and with the other Cluster API objects, as described in Part VII, “Fully automated directed network provisioning”.

Note
Note
  • This approach is convenient only if the hardware in the cluster is uniform and the same configuration is needed on all hosts, interface name included.

  • Alternative approaches are possible and will be covered in future releases.

At this point, your hosts should have a working and running PTP stack and will start negotiating their PTP role.

46.4 PTP on Intel Granite Rapids-D platforms

SUSE Telco Cloud supports precise timing on a variety of different platforms, including the latest Intel Granite Rapids-D based designs (GNR-D). These new servers typically include an embedded high-speed Ethernet controller and one or more add-in cards with an Ethernet controller for additional ports. Contrary to previous platform generations, they are also equipped with a dedicated DPLL that allows the routing of the timing signals across the system and the different NICS, and no longer requires external cabling. The overall deployment is thus simplified, but specific steps and software components are required, such as boot time DPLL and internal signal configuration.

Before going through the setup steps, download and install the latest kernel driver for the Intel 800 Series Network Devices from the Intel website. Select the zip file containing the "ice_RPM_Files" and unpack the archive, then install the ice-kmp-default-*sles16sp0.x86_64.rpm RPM there contained, for example file ice-kmp-default-2.4.5_k6.12.0_160000.5-1.sles16sp0.x86_64.rpm:

# transactional-update pkg install ice-kmp-default-2.4.5_k6.12.0_160000.5-1.sles16sp0.x86_64.rpm

Reboot the server to make the change persistent and effective.

Note
Note
  • A Dell PowerEdge XR8720t system will be used as the reference system through the examples, the kernel interfaces and port configuration might be different on a different GNR-D server.

  • A Telco deployment is assumed and the Telco profile G.8275.1 used through the following sections for PTP.

46.4.1 PTP Boundary Clock

This section describes the process of setting up a Boundary Clock (BC) on a GNR-D system, where one port on the integrated NIC receives the PTP timestamps from a GM and all the remaining ports in the system act as Time Transmitters towards other network nodes.

Note
Note

The setup described here is completely static. If the GM becomes unavailable, the downstream synchronization will exclusively rely on the host holdhover capabilities; no automatic switching to a different source of time reference will be performed.

To enable the BC behavior, run the following steps in the same order every time the system is booted:

  1. Verify the expected PTP devices that control the PHCs are present:

    # ls -l /sys/class/ptp/
    total 0
    lrwxrwxrwx. 1 root root 0 Apr 27 20:21 ptp1 -> ../../devices/pci0000:12/0000:12:04.0/0000:13:00.0/ptp/ptp1
    lrwxrwxrwx. 1 root root 0 Apr 27 20:21 ptp2 -> ../../devices/pci0000:6b/0000:6b:02.0/0000:6c:00.0/ptp/ptp2
    lrwxrwxrwx. 1 root root 0 Apr 27 20:21 ptp3 -> ../../devices/pci0000:6b/0000:6b:06.0/0000:6e:00.0/ptp/ptp3
    Note
    Note

    Adjust the subsequent commands according to the actual names found on the system being configured.

  2. Identify the embedded controller, as it will require specific configuration:

    The previous output should indicate the device to which they are bound to through the PCI address and you can use lspci to look up the device type:

    # lspci -s 0000:13:00.0
    13:00.0 Ethernet controller: Intel Corporation Ethernet Connection E825-C for SFP (rev 04)
    # lspci -s 0000:6c:00.0
    6c:00.0 Ethernet controller: Intel Corporation Ethernet Controller E830-CC for SFP
    # lspci -s 0000:6e:00.0
    6e:00.0 Ethernet controller: Intel Corporation Ethernet Controller E830-CC for SFP

    This specific server is equipped with an Intel E825-C embedded controller and two E830-CC add-in cards.

    Alternatively, you can find more information about the controller by looking up the first network port of the controller that exposes that PHC:

    # ls -l /sys/class/ptp/ptp0/device/net/
    total 0
    drwxr-xr-x. 5 root root 0 Apr 30 15:16 em5
    # ethtool -i em5
    driver: ice
    version: 2.4.5
    firmware-version: 4.03 0x80007f91 1.3881.0
    expansion-rom-version:
    bus-info: 0000:13:00.0
    [...]

    Note that em5 is the first port of the integrated Ethernet controller on this system.

  3. Configure the signals between the PHC on the integrated Ethernet controller and the system timing DPLL:

    1. Let the DPLL drive the Ethernet clock on the integrated controller:

      # echo 4 1 > /sys/class/net/em5/device/tspll_cfg
    2. Enable a pulse every top of second (Pulse Per Second, PPS) from the PHC to the DPLL through the SDP2 pin (1kHz signal):

      # echo 2 1 > /sys/class/ptp/ptp1/pins/SDP2
      # echo 1 0 0 0 1000000 > /sys/class/ptp/ptp1/period
    3. Optionally, pin SPD0 (1Hz signal) can be enabled too:

      # echo 2 2 > /sys/class/ptp/ptp1/pins/SDP0
      # echo 2 0 0 1 0 > /sys/class/ptp/ptp1/period
    4. Enable the 1 PPS signal to be propagated from the timing system DPLL to the additional add-in cards:

      # echo 1 1 > /sys/class/ptp/ptp2/pins/SDP1
      # echo 1 1 > /sys/class/ptp/ptp3/pins/SDP1
  4. Run ts2phc to keep PHCs of the add-in cards in sync with the same timestamp of PHC /dev/ptp1:

    # ts2phc -f ts2phc-aic-all.cfg -s /dev/ptp1

    Refer to Section 46.4.2.3, “ts2phc configuration file for add-in cards” for the content of ts2phc-aic-all.cfg.

  5. Run an instance of ptp4l for the integrated controller (/dev/ptp1):

    # ptp4l -f ptp4l-G.8275.1-nac.conf

    Refer to Section 46.4.2.1, “ptp4l configuration file for the integrated controller (/dev/ptp1)” for the content of ptp4l-G.8275.1-nac.conf.

  6. Run an instance of ptp4l for each add-in card (/dev/ptp3 and/or /dev/ptp2):

    # ptp4l -f ptp4l-G.8275.1-aic1.conf
    # ptp4l -f ptp4l-G.8275.1-aic2.conf

    Refer to Section 46.4.2.2, “ptp4l configuration file for add-in cards (/dev/ptp2 or /dev/ptp3)” for the content of the configuration files.

    Note
    Note

    To prevent conflicts and enable the next step, each of these instances must use different control and read-only sockets.

  7. Synchronize the PTP runtime parameters and values of the AICs ptp4l instances with pmc:

    A BC is expected to forward not only the time of a GM it is connected to, but also ancillary parameters, such as its clock class and accuracy level. This happens automatically within a group of interfaces managed by the same ptp4l instance, but not accross different ptp4l instances, handling different PHCs and ports.

    Once the system is synchronized to a GM, query the ptp4l instance on the integrated controller and set the values on the remaining ptp4l instances via pmc commands. For example:

    # pmc -f /etc/ptp4l-G.8275.1-nac-bmca.conf -u -b 0 'GET PARENT_DATA_SET' | grep gm
                    gm.ClockClass                         8
                    gm.ClockAccuracy                      0xfe
                    gm.OffsetScaledLogVariance            0xffff
    # pmc -f /etc/ptp4l-G.8275.1-nac-bmca.conf -u -b 0 'GET TIME_PROPERTIES_DATA_SET' | grep -v PROPERTIES
                    currentUtcOffset      37
                    leap61                0
                    leap59                0
                    currentUtcOffsetValid 0
                    ptpTimescale          1
                    timeTraceable         0
                    frequencyTraceable    0
                    timeSource            0xa0
    pmc -f /etc/ptp4l-G.8275.1-aic1-static.conf -u -b 0 'SET GRANDMASTER_SETTINGS_NP
                    clockClass              8
                    clockAccuracy           0xfe
                    offsetScaledLogVariance 0xffff
                    currentUtcOffset        37
                    leap61                  0
                    leap59                  0
                    currentUtcOffsetValid   0
                    ptpTimescale            1
                    timeTraceable           0
                    frequencyTraceable      0
                    timeSource              0xa0

    Refer to Section 46.4.2.4, “GM parameters forwarding script” to automate this process and avoid manual steps.

  8. Optionally run phc2sys to derive the system time from the PTP synchronization:

    # phc2sys -f /etc/ptp4l-G.8275.1-nac.conf -s /dev/ptp1 -c CLOCK_REALTIME -w

    The input file is the same configuration file used for ptp4l and the integrated controller. See Section 46.2.4, “Synchronization of the system clock from PTP” for letting systemd handle its execution.

46.4.2 Configuration files

This section provides sample configuration files and scripts that can be used in conjunction with the above steps to quickly set up a working BC on GNR-D. The ptp4l configuration files contain all the required settings, without the need for additional external execution flags, and are all based around the Telco profile G.8275.1. More details are provided for each file in their respective sections.

46.4.2.1 ptp4l configuration file for the integrated controller (/dev/ptp1)

[global]
domainNumber                    24
priority2                       255
dataset_comparison              G.8275.x
G.8275.portDS.localPriority     128
G.8275.defaultDS.localPriority  128
maxStepsRemoved                 255
logAnnounceInterval             -3
logSyncInterval                 -4
logMinDelayReqInterval          -4
announceReceiptTimeout          3
ptp_dst_mac                     01:1b:19:00:00:00
network_transport               L2
summary_interval                3
message_tag                     "ptp4l-nac"
uds_address                     /var/run/ptp4l-nac
uds_ro_address                  /var/run/ptp4lro-nac

[em1]

[em2]

[em3]

[em4]

The above configuration leverages the BMCA to determine the role of the port, assuming a GM is available through one of them. If tighter control is needed, add the serverOnly flag under each interface definition. For more details, refer to Section 46.2.3, “PTP configuration of a Boundary Clock” or to the add-in cards configuration below as an example. For the sake of brevity, only four interfaces are listed, you need to adjust according to your requirements.

46.4.2.2 ptp4l configuration file for add-in cards (/dev/ptp2 or /dev/ptp3)

# Telecom G.8275.1 example configuration
[global]
domainNumber                    24
priority2                       255
dataset_comparison              G.8275.x
G.8275.portDS.localPriority     250
G.8275.defaultDS.localPriority  250
maxStepsRemoved                 255
logAnnounceInterval             -3
logSyncInterval                 -4
logMinDelayReqInterval          -4
announceReceiptTimeout          3
ptp_dst_mac                     01:1b:19:00:00:00
network_transport               L2
summary_interval                3
message_tag                     "ptp4l-iac1"
uds_address                     /var/run/ptp4l-aic1
uds_ro_address                  /var/run/ptp4lro-aic1

[p1p1]
serverOnly                      1

[p1p2]
serverOnly                      1

[p1p3]
serverOnly                      1

[p1p4]
serverOnly                      1

For the sake of brevity, only four interfaces are listed. You need to adjust according to your requirements. All the interfaces have been statically set to the TimeTransmitter role.

46.4.2.3 ts2phc configuration file for add-in cards

[global]
use_syslog              0
verbose                 1
logging_level           7
ts2phc.pulsewidth       100000000

[p1p1]
ts2phc.channel          1
ts2phc.extts_polarity   rising
ts2phc.pin_index        1

[p2p1]
ts2phc.channel          1
ts2phc.extts_polarity   rising
ts2phc.pin_index        1

This configuration covers the synchronization of two add-in cards (referenced by their first port, p1p1 and p2p1) via the SDP1 on each controller.

46.4.2.4 GM parameters forwarding script

The script below can be leveraged to forward the GM values and parameters to Time Receivers on ports handled by ptp4l instances other than the one where the GM lives. Do not forget to edit the Input variables section to adjust the file names and run it once the system is sychronized to a GM.

#!/bin/bash

set -euo pipefail

################## Input variables ##################
VERBOSE=1

CONFIG_FILE_NAC=/etc/ptp4l-G.8275.1-nac-bmca.conf
CONFIG_FILES_AICS=(/etc/ptp4l-G.8275.1-aic1-static.conf /etc/ptp4l-G.8275.1-aic2-static.conf)

#####################################################


# Check the system is synchronized to a GM
GM_PRESENT=$(pmc -f ${CONFIG_FILE_NAC} -u -b 0 'GET TIME_STATUS_NP' | awk '/gmPresent/ {print $2}')

if [ "${GM_PRESENT}" != "true" ]; then
    echo "No GM present, exiting..."
    exit 1
fi

# Get the "upstream" Grand Master values

PDS_GM_VALUES=$(pmc -f ${CONFIG_FILE_NAC} -u -b 0 'GET PARENT_DATA_SET' | awk 'BEGIN {ORS=" "} /gm./ {print $2}')
TPDS_GM_VALUES=$(pmc -f ${CONFIG_FILE_NAC} -u -b 0 'GET TIME_PROPERTIES_DATA_SET' | awk 'BEGIN {ORS=" "} NR>2 {print $2}')

if [ -z "$PDS_GM_VALUES" ]; then
    echo "No PARENT_DATA_SET values retrieved"
    exit 2
elif [ -z "$TPDS_GM_VALUES" ]; then
    echo "No TIME_PROPERTIES_DATA_SET values retrieved"
    exit 2
fi

# Unpack from PARENT_DATA_SET
read CLOCK_CLASS CLOCK_ACCURACY VARIANCE <<< $PDS_GM_VALUES

# Unpack from TIME_PROPERTIES_DATA_SET
read UTC_OFFSET LEAP_61 LEAP_59 UTC_OFFSET_VALID PTP_TIMESCALE T_TRACEABLE F_TRACEABLE T_SOURCE <<< $TPDS_GM_VALUES

if [ "$VERBOSE" -eq 1 ]; then
    echo "Read from PARENT_DATA_SET: clockClass=${CLOCK_CLASS} clockAccuracy=${CLOCK_ACCURACY} offsetScaledLogVariance=${VARIANCE}"
    echo "Read from TIME_PROPERTIES_DATA_SET: currentUtcOffset=${UTC_OFFSET} leap61=${LEAP_61} leap59=${LEAP_59}" \
         "currentUtcOffsetValid=${UTC_OFFSET_VALID} ptpTimescale=${PTP_TIMESCALE} timeTraceable=${T_TRACEABLE}" \
         "frequencyTraceable=${F_TRACEABLE} timeSource=${T_SOURCE}"
fi


# Forward these values to the "downstream" Time Receivers updating the ptp4l instances

for FILE in "${CONFIG_FILES_AICS[@]}"; do
    if [ "$VERBOSE" -eq 1 ]; then
        echo "Updating GRANDMASTER_SETTINGS_NP (${FILE})"
    fi

    pmc -f ${FILE} -u -b 0 'SET GRANDMASTER_SETTINGS_NP
       clockClass              '${CLOCK_CLASS}'
       clockAccuracy           '${CLOCK_ACCURACY}'
       offsetScaledLogVariance '${VARIANCE}'
       currentUtcOffset        '${UTC_OFFSET}'
       leap61                  '${LEAP_61}'
       leap59                  '${LEAP_59}'
       currentUtcOffsetValid   '${UTC_OFFSET_VALID}'
       ptpTimescale            '${PTP_TIMESCALE}'
       timeTraceable           '${T_TRACEABLE}'
       frequencyTraceable      '${F_TRACEABLE}'
       timeSource              '${T_SOURCE}'' &> /dev/null

    if [ $? -ne 0 ]; then
        echo "Failed to update ${FILE}"
    fi
done
Note
Note

The script must run every time the GM changes.