diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml index c19d5319b998..e82e72baf136 100644 --- a/_topic_maps/_topic_map.yml +++ b/_topic_maps/_topic_map.yml @@ -1504,10 +1504,10 @@ Topics: - Name: Using Stream Control Transmission Protocol File: using-sctp Distros: openshift-enterprise,openshift-origin -- Name: Using Precision Time Protocol hardware +- Name: Using PTP hardware Dir: ptp Topics: - - Name: About Precision Time Protocol in OpenShift cluster nodes + - Name: About PTP in OpenShift cluster nodes File: about-ptp - Name: Configuring PTP devices File: configuring-ptp diff --git a/images/561_OpenShift_Using_PTP_network_0124.png b/images/561_OpenShift_Using_PTP_network_0124.png deleted file mode 100644 index 8973b436a5a8..000000000000 Binary files a/images/561_OpenShift_Using_PTP_network_0124.png and /dev/null differ diff --git a/images/openshift-ptp-3-card-grandmaster.png b/images/openshift-ptp-3-card-grandmaster.png new file mode 100644 index 000000000000..5fa8d8032d2d Binary files /dev/null and b/images/openshift-ptp-3-card-grandmaster.png differ diff --git a/images/openshift-ptp-using-dual-nic-ptp.png b/images/openshift-ptp-using-dual-nic-ptp.png new file mode 100644 index 000000000000..90176f0860b0 Binary files /dev/null and b/images/openshift-ptp-using-dual-nic-ptp.png differ diff --git a/modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-dual-nic.adoc b/modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-dual-nic.adoc index e7a91529435a..b92198ddfdb5 100644 --- a/modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-dual-nic.adoc +++ b/modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-dual-nic.adoc @@ -4,21 +4,22 @@ :_mod-docs-content-type: PROCEDURE [id="configuring-linuxptp-services-as-grandmaster-clock-dual-nic_{context}"] -= Configuring linuxptp services as a grandmaster clock for dual E810 NICs += Configuring linuxptp services as a grandmaster clock for dual E810 Westport Channel NICs -You can configure the `linuxptp` services (`ptp4l`, `phc2sys`, `ts2phc`) as a grandmaster clock (T-GM) for dual E810 NICs by creating a `PtpConfig` custom resource (CR) that configures the host NICs. +You can configure the `linuxptp` services (`ptp4l`, `phc2sys`, `ts2phc`) as a grandmaster clock (T-GM) for 2 E810 NICs by creating a `PtpConfig` custom resource (CR) that configures the NICs. -You can configure the `linuxptp` services as a T-GM for the following dual E810 NICs: +You can configure the `linuxptp` services as a T-GM for the following E810 NICs: -* Intel E810-XXVDA4T Westport Channel NICs -* Intel E810-CQDA2T Logan Beach NICs +* Intel E810-XXVDA4T Westport Channel NIC +* Intel E810-CQDA2T Logan Beach NIC -For distributed RAN (D-RAN) use cases, you can configure PTP for dual-NICs as follows: +For distributed RAN (D-RAN) use cases, you can configure PTP for 2 NICs as follows: -* NIC one is synced to the global navigation satellite system (GNSS) time source. -* NIC two is synced to the 1PPS timing output provided by NIC one. This configuration is provided by the PTP hardware plugin in the `PtpConfig` CR. +* NIC 1 is synced to the global navigation satellite system (GNSS) time source. +* NIC 2 is synced to the 1PPS timing output provided by NIC one. This configuration is provided by the PTP hardware plugin in the `PtpConfig` CR. -The dual-NIC PTP T-GM configuration uses a single instance of `ptp4l` and one `ts2phc` process reporting two `ts2phc` instances, one for each NIC. +The 2-card PTP T-GM configuration uses one instance of `ptp4l` and one instance of `ts2phc`. +The `ptp4l` and `ts2phc` programs are each configured to operate on two PTP hardware clocks (PHCs), one for each NIC. The host system clock is synchronized from the NIC that is connected to the GNSS time source. [NOTE] diff --git a/modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-three-nic.adoc b/modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-three-nic.adoc new file mode 100644 index 000000000000..0679a119a0fa --- /dev/null +++ b/modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-three-nic.adoc @@ -0,0 +1,106 @@ +// Module included in the following assemblies: +// +// * networking/ptp/configuring-ptp.adoc + +:_mod-docs-content-type: PROCEDURE +[id="configuring-linuxptp-services-as-grandmaster-clock-three-nic_{context}"] += Configuring linuxptp services as a grandmaster clock for 3 E810 NICs + +You can configure the `linuxptp` services (`ptp4l`, `phc2sys`, `ts2phc`) as a grandmaster clock (T-GM) for 3 E810 NICs by creating a `PtpConfig` custom resource (CR) that configures the NICs. + +You can configure the `linuxptp` services as a T-GM with 3 NICs for the following E810 NICs: + +* Intel E810-XXVDA4T Westport Channel NIC +* Intel E810-CQDA2T Logan Beach NIC + +For distributed RAN (D-RAN) use cases, you can configure PTP for 3 NICs as follows: + +* NIC 1 is synced to the Global Navigation Satellite System (GNSS) +* NICs 2 and 3 are synced to NIC 1 with 1PPS faceplate connections + +Use the following example `PtpConfig` CRs as the basis to configure `linuxptp` services as a 3-card Intel E810 T-GM. + +.Prerequisites + +* For T-GM clocks in production environments, install 3 Intel E810 NICs in the bare-metal cluster host. + +* Install the OpenShift CLI (`oc`). + +* Log in as a user with `cluster-admin` privileges. + +* Install the PTP Operator. + +.Procedure + +. Create the `PtpConfig` CR. For example: + +.. Save the following YAML in the `three-nic-grandmaster-clock-ptp-config.yaml` file: ++ +.PTP grandmaster clock configuration for 3 E810 NICs +[%collapsible] +==== +[source,yaml] +---- +include::snippets/ptp_PtpConfigThreeCardGmWpc.yaml[] +---- +==== ++ +[NOTE] +==== +Set the value for `ts2phc.nmea_serialport` to `/dev/gnss0`. +==== + +.. Create the CR by running the following command: ++ +[source,terminal] +---- +$ oc create -f three-nic-grandmaster-clock-ptp-config.yaml +---- + +.Verification + +. Check that the `PtpConfig` profile is applied to the node. + +.. Get the list of pods in the `openshift-ptp` namespace by running the following command: ++ +[source,terminal] +---- +$ oc get pods -n openshift-ptp -o wide +---- ++ +.Example output +[source,terminal] +---- +NAME READY STATUS RESTARTS AGE IP NODE +linuxptp-daemon-74m3q 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com +ptp-operator-5f4f48d7c-x6zkn 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com +---- + +.. Check that the profile is correct. Run the following command, and examine the logs of the `linuxptp` daemon that corresponds to the node you specified in the `PtpConfig` profile: ++ +[source,terminal] +---- +$ oc logs linuxptp-daemon-74m3q -n openshift-ptp -c linuxptp-daemon-container +---- ++ +.Example output +[source,terminal] +---- +ts2phc[2527.586]: [ts2phc.0.config:7] adding tstamp 1742826342.000000000 to clock /dev/ptp11 <1> +ts2phc[2527.586]: [ts2phc.0.config:7] adding tstamp 1742826342.000000000 to clock /dev/ptp7 <1> +ts2phc[2527.586]: [ts2phc.0.config:7] adding tstamp 1742826342.000000000 to clock /dev/ptp14 <1> +ts2phc[2527.586]: [ts2phc.0.config:7] nmea delay: 56308811 ns +ts2phc[2527.586]: [ts2phc.0.config:6] /dev/ptp14 offset 0 s2 freq +0 <2> +ts2phc[2527.587]: [ts2phc.0.config:6] /dev/ptp7 offset 0 s2 freq +0 <2> +ts2phc[2527.587]: [ts2phc.0.config:6] /dev/ptp11 offset 0 s2 freq -0 <2> +I0324 14:25:05.000439 106907 stats.go:61] state updated for ts2phc =s2 +I0324 14:25:05.000504 106907 event.go:419] dpll State s2, gnss State s2, tsphc state s2, gm state s2, +I0324 14:25:05.000906 106907 stats.go:61] state updated for ts2phc =s2 +I0324 14:25:05.001059 106907 stats.go:61] state updated for ts2phc =s2 +ts2phc[1742826305]:[ts2phc.0.config] ens4f0 nmea_status 1 offset 0 s2 +GM[1742826305]:[ts2phc.0.config] ens4f0 T-GM-STATUS s2 <3> +---- +<1> `ts2phc` is updating the PTP hardware clock. +<2> Estimated PTP device offset between PTP device and the reference clock is 0 nanoseconds. +The PTP device is in sync with the leader clock. +<3> T-GM is in a locked state (s2). diff --git a/modules/nw-ptp-grandmaster-clock-class-reference.adoc b/modules/nw-ptp-grandmaster-clock-class-reference.adoc index d242538b2211..8e6d009b680a 100644 --- a/modules/nw-ptp-grandmaster-clock-class-reference.adoc +++ b/modules/nw-ptp-grandmaster-clock-class-reference.adoc @@ -25,9 +25,6 @@ For example, the PRTC is traceable to a GNSS time source. |T-GM clock is in `HOLDOVER` mode, and within holdover specification. The clock source might not be traceable to a category 1 frequency source. -|`gm.ClockClass 140` -|T-GM clock is in `HOLDOVER` mode, is out of holdover specification, but it is still traceable to the category 1 frequency source. - |`gm.ClockClass 248` |T-GM clock is in `FREERUN` mode. |==== diff --git a/modules/nw-ptp-three-nic-hardware-config-reference.adoc b/modules/nw-ptp-three-nic-hardware-config-reference.adoc new file mode 100644 index 000000000000..648bbe168739 --- /dev/null +++ b/modules/nw-ptp-three-nic-hardware-config-reference.adoc @@ -0,0 +1,41 @@ +// Module included in the following assemblies: +// +// * networking/ptp/configuring-ptp.adoc + +:_mod-docs-content-type: REFERENCE +[id="nw-ptp-three-nic-hardware-config-reference_{context}"] += 3-card E810 NIC configuration reference + +Use this information to understand how to configure 3 E810 NICs as PTP grandmaster clock (T-GM). + +Before you configure the 3-card cluster host, you must connect the 3 NICs by using the 1PPS faceplate connections. +The primary NIC `1PPS_out` outputs feed the other 2 NICs. + +When you configure a 3-card T-GM, you need to compensate for the 1PPS signal delay that occurs when you connect the NICs by using the SMA1 connection ports. +Various factors such as cable length, ambient temperature, and component and manufacturing tolerances can affect the signal delay. +To compensate for the delay, you must calculate the specific value that you use to offset the signal delay. + +.3-card E810 T-GM PtpConfig CR reference +[cols="1,2" width="90%", options="header"] +|==== +|PtpConfig field +|Description + +|`spec.profile.plugins.e810.pins` +a|Configure the E810 hardware pins with the PTP Operator E810 hardware plugin. + +* `$iface_timeTx1.SMA1` enables the `1PPS OUT` connection for `SMA1` on NIC 1. +* `$iface_timeTx1.SMA2` enables the `1PPS OUT` connection for `SMA2` on NIC 1. +* `$iface_timeTx2.SMA1` and `$iface_timeTx3.SMA1` enables the `1PPS IN` connection for `SMA1` on NIC 2 and NIC 3. +* `$iface_timeTx2.SMA2` and `$iface_timeTx3.SMA2` disables the `SMA2` connection on NIC 2 and NIC 3. + +|`spec.profile.ts2phcConf` +|Use the `ts2phcConf` field to configure parameters for the NICs. +Set `ts2phc.master 0` for NIC 2 and NIC 3. +This configures the timing source for NIC 2 and NIC 3 from the 1PPS input, not GNSS. +Configure the `ts2phc.extts_correction` value for NIC 2 and NIC 3 to compensate for the delay that is incurred for the specific SMA cable and cable length that you use. +The value that you configure depends on your specific measurements and SMA1 cable length. + +|`spec.profile.ptp4lConf` +|Set the value of `boundary_clock_jbod` to 1 to enable support for multiple NICs. +|==== diff --git a/modules/ptp-dual-nics.adoc b/modules/ptp-dual-nics.adoc index 89547f1b6592..c164659dc704 100644 --- a/modules/ptp-dual-nics.adoc +++ b/modules/ptp-dual-nics.adoc @@ -4,40 +4,49 @@ :_mod-docs-content-type: CONCEPT [id="ptp-dual-nics_{context}"] -= Using dual-NIC Intel E810 hardware with PTP += 2-card E810 NIC configuration reference -{product-title} supports single and dual-NIC Intel E810 hardware for precision PTP timing in grandmaster clocks (T-GM) and boundary clocks (T-BC). +{product-title} supports single and dual-NIC Intel E810 hardware for PTP timing in grandmaster clocks (T-GM) and boundary clocks (T-BC). Dual NIC grandmaster clock:: ++ +-- You can use a cluster host that has dual-NIC hardware as PTP grandmaster clock. One NIC receives timing information from the global navigation satellite system (GNSS). The second NIC receives the timing information from the first using the SMA1 Tx/Rx connections on the E810 NIC faceplate. The system clock on the cluster host is synchronized from the NIC that is connected to the GNSS satellite. -+ + Dual NIC grandmaster clocks are a feature of distributed RAN (D-RAN) configurations where the Remote Radio Unit (RRU) and Baseband Unit (BBU) are located at the same radio cell site. D-RAN distributes radio functions across multiple sites, with backhaul connections linking them to the core network. -+ + .Dual NIC grandmaster clock -image::561_OpenShift_Using_PTP_network_0124.png[Dual NIC PTP grandmaster clock connected to GNSS timing source and downstream PTP boundary and ordinary clocks] -+ +image::openshift-ptp-using-dual-nic-ptp.png[Dual NIC PTP grandmaster clock connected to GNSS timing source and downstream PTP boundary and ordinary clocks] + [NOTE] ==== -In a dual-NIC T-GM configuration, a single `ts2phc` process reports as two `ts2phc` instances in the system. +In a dual-NIC T-GM configuration, a single `ts2phc` program operate on two PTP hardware clocks (PHCs), one for each NIC. ==== +-- Dual NIC boundary clock:: -For 5G telco networks that deliver mid-band spectrum coverage, each virtual distributed unit (vDU) requires connections to 6 radio units (RUs). To make these connections, each vDU host requires 2 NICs configured as boundary clocks. + +-- +For 5G telco networks that deliver mid-band spectrum coverage, each virtual distributed unit (vDU) requires connections to 6 radio units (RUs). To make these connections, each vDU host requires 2 NICs configured as boundary clocks. + Dual NIC hardware allows you to connect each NIC to the same upstream leader clock with separate `ptp4l` instances for each NIC feeding the downstream clocks. +-- Highly available system clock with dual-NIC boundary clocks:: -You can configure Intel E810-XXVDA4 Salem channel dual-NIC hardware as dual PTP boundary clocks that provide timing for a highly available system clock. -This is useful when you have multiple time sources on different NICs. -High availability ensures that the node does not lose timing synchronisation if one of the two timing sources is lost or disconnected. + +-- +You can configure Intel E810-XXVDA4 Salem channel dual-NIC hardware as dual PTP boundary clocks that provide timing for a highly available system clock. +This configuration is useful when you have multiple time sources on different NICs. +High availability ensures that the node does not lose timing synchronization if one of the two timing sources is lost or disconnected. + Each NIC is connected to the same upstream leader clock. Highly available boundary clocks use multiple PTP domains to synchronize with the target system clock. When a T-BC is highly available, the host system clock can maintain the correct offset even if one or more `ptp4l` instances syncing the NIC PHC clock fails. If any single SFP port or cable failure occurs, the boundary clock stays in sync with the leader clock. -+ + Boundary clock leader source selection is done using the A-BMCA algorithm. For more information, see link:https://www.itu.int/rec/T-REC-G.8275.1/en[ITU-T recommendation G.8275.1]. +-- diff --git a/modules/ptp-three-card-grandmaster.adoc b/modules/ptp-three-card-grandmaster.adoc new file mode 100644 index 000000000000..8ef065370ba0 --- /dev/null +++ b/modules/ptp-three-card-grandmaster.adoc @@ -0,0 +1,29 @@ +// Module included in the following assemblies: +// +// * networking/ptp/about-ptp.adoc + +:_mod-docs-content-type: CONCEPT +[id="ptp-three-card-grandmaster_{context}"] += 3-card Intel E810 PTP grandmaster clock + +{product-title} supports cluster hosts with 3 Intel E810 NICs as PTP grandmaster clocks (T-GM). + +3-card grandmaster clock:: ++ +-- +You can use a cluster host that has 3 NICs as PTP grandmaster clock. +One NIC receives timing information from the global navigation satellite system (GNSS). +The second and third NICs receive the timing information from the first by using the SMA1 Tx/Rx connections on the E810 NIC faceplate. +The system clock on the cluster host is synchronized from the NIC that is connected to the GNSS satellite. + +3-card NIC grandmaster clocks can be used for distributed RAN (D-RAN) configurations where the Radio Unit (RU) is connected directly to the distributed unit (DU) without a front haul switch, for example, if the RU and DU are located in the same radio cell site. +D-RAN distributes radio functions across multiple sites, with backhaul connections linking them to the core network. + +.3-card Intel E810 PTP grandmaster clock +image::openshift-ptp-3-card-grandmaster.png[3-card PTP grandmaster clock connected to GNSS timing source and downstream PTP boundary and ordinary clocks] + +[NOTE] +==== +In a 3-card T-GM configuration, a single `ts2phc` process reports as 3 `ts2phc` instances in the system. +==== +-- diff --git a/networking/ptp/about-ptp.adoc b/networking/ptp/about-ptp.adoc index 4cfaa2b54d1a..1e0f755f0f80 100644 --- a/networking/ptp/about-ptp.adoc +++ b/networking/ptp/about-ptp.adoc @@ -30,10 +30,12 @@ include::modules/nw-ptp-introduction.adoc[leveloffset=+1] Before enabling PTP, ensure that NTP is disabled for the required nodes. You can disable the chrony time service (`chronyd`) using a `MachineConfig` custom resource. For more information, see xref:../../machine_configuration/machine-configs-configure.adoc#cnf-disable-chronyd_machine-configs-configure[Disabling chrony time service]. ==== -include::modules/ptp-dual-nics.adoc[leveloffset=+1] - include::modules/ptp-linuxptp-introduction.adoc[leveloffset=+1] include::modules/ptp-overview-of-gnss-grandmaster-clock.adoc[leveloffset=+1] include::modules/cnf-about-ptp-and-clock-synchronization.adoc[leveloffset=+1] + +include::modules/ptp-dual-nics.adoc[leveloffset=+1] + +include::modules/ptp-three-card-grandmaster.adoc[leveloffset=+1] diff --git a/networking/ptp/configuring-ptp.adoc b/networking/ptp/configuring-ptp.adoc index eff0cc768e90..415f65ed0139 100644 --- a/networking/ptp/configuring-ptp.adoc +++ b/networking/ptp/configuring-ptp.adoc @@ -25,14 +25,16 @@ include::modules/nw-ptp-device-discovery.adoc[leveloffset=+1] include::modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock.adoc[leveloffset=+1] -include::modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-dual-nic.adoc[leveloffset=+1] +include::modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-dual-nic.adoc[leveloffset=+2] + +include::modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock-three-nic.adoc[leveloffset=+2] [role="_additional-resources"] .Additional resources * xref:../../networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc#cnf-configuring-the-ptp-fast-event-publisher-v2_ptp-consumer[Configuring the PTP fast event notifications publisher] -include::modules/nw-ptp-grandmaster-clock-configuration-reference.adoc[leveloffset=+2] +include::modules/nw-ptp-grandmaster-clock-configuration-reference.adoc[leveloffset=+1] include::modules/nw-ptp-grandmaster-clock-class-reference.adoc[leveloffset=+2] @@ -40,6 +42,8 @@ include::modules/nw-ptp-e810-hardware-configuration-reference.adoc[leveloffset=+ include::modules/nw-ptp-dual-wpc-hardware-config-reference.adoc[leveloffset=+2] +include::modules/nw-ptp-three-nic-hardware-config-reference.adoc[leveloffset=+2] + include::modules/ptp-configuring-dynamic-leap-seconds-handling-for-tgm.adoc[leveloffset=+1] include::modules/nw-ptp-configuring-linuxptp-services-as-boundary-clock.adoc[leveloffset=+1] diff --git a/snippets/ptp_PtpConfigThreeCardGmWpc.yaml b/snippets/ptp_PtpConfigThreeCardGmWpc.yaml new file mode 100644 index 000000000000..555bc3794b5d --- /dev/null +++ b/snippets/ptp_PtpConfigThreeCardGmWpc.yaml @@ -0,0 +1,267 @@ +# In this example, the three cards are connected via SMA cables: +# - $iface_timeTx1 has the GNSS signal input +# - $iface_timeTx2 SMA1 is connected to $iface_timeTx1 SMA1 +# - $iface_timeTx3 SMA1 is connected to $iface_timeTx1 SMA2 +apiVersion: ptp.openshift.io/v1 +kind: PtpConfig +metadata: + name: gm-3card + namespace: openshift-ptp + annotations: + ran.openshift.io/ztp-deploy-wave: "10" +spec: + profile: + - name: grandmaster + ptp4lOpts: -2 --summary_interval -4 + phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_timeTx1 -n 24 + ptpSchedulingPolicy: SCHED_FIFO + ptpSchedulingPriority: 10 + ptpSettings: + logReduce: "true" + plugins: + e810: + enableDefaultConfig: false + settings: + LocalHoldoverTimeout: 14400 + LocalMaxHoldoverOffSet: 1500 + MaxInSpecOffset: 1500 + pins: + # Syntax guide: + # - The 1st number in each pair must be one of: + # 0 - Disabled + # 1 - RX + # 2 - TX + # - The 2nd number in each pair must match the channel number + $iface_timeTx1: + SMA1: 2 1 + SMA2: 2 2 + U.FL1: 0 1 + U.FL2: 0 2 + $iface_timeTx2: + SMA1: 1 1 + SMA2: 0 2 + U.FL1: 0 1 + U.FL2: 0 2 + $iface_timeTx3: + SMA1: 1 1 + SMA2: 0 2 + U.FL1: 0 1 + U.FL2: 0 2 + ublxCmds: + - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1 + - "-P" + - "29.20" + - "-z" + - "CFG-HW-ANT_CFG_VOLTCTRL,1" + reportOutput: false + - args: #ubxtool -P 29.20 -e GPS + - "-P" + - "29.20" + - "-e" + - "GPS" + reportOutput: false + - args: #ubxtool -P 29.20 -d Galileo + - "-P" + - "29.20" + - "-d" + - "Galileo" + reportOutput: false + - args: #ubxtool -P 29.20 -d GLONASS + - "-P" + - "29.20" + - "-d" + - "GLONASS" + reportOutput: false + - args: #ubxtool -P 29.20 -d BeiDou + - "-P" + - "29.20" + - "-d" + - "BeiDou" + reportOutput: false + - args: #ubxtool -P 29.20 -d SBAS + - "-P" + - "29.20" + - "-d" + - "SBAS" + reportOutput: false + - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000 + - "-P" + - "29.20" + - "-t" + - "-w" + - "5" + - "-v" + - "1" + - "-e" + - "SURVEYIN,600,50000" + reportOutput: true + - args: #ubxtool -P 29.20 -p MON-HW + - "-P" + - "29.20" + - "-p" + - "MON-HW" + reportOutput: true + - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 + - "-P" + - "29.20" + - "-p" + - "CFG-MSG,1,38,248" + reportOutput: true + ts2phcOpts: " " + ts2phcConf: | + [nmea] + ts2phc.master 1 + [global] + use_syslog 0 + verbose 1 + logging_level 7 + ts2phc.pulsewidth 100000000 + #example value of nmea_serialport is /dev/gnss0 + ts2phc.nmea_serialport (?[/\w\s/]+) + leapfile /usr/share/zoneinfo/leap-seconds.list + [$iface_timeTx1] + ts2phc.extts_polarity rising + ts2phc.extts_correction 0 + [$iface_timeTx2] + ts2phc.master 0 + ts2phc.extts_polarity rising + #this is a measured value in nanoseconds to compensate for SMA cable delay + ts2phc.extts_correction -10 + [$iface_timeTx3] + ts2phc.master 0 + ts2phc.extts_polarity rising + #this is a measured value in nanoseconds to compensate for SMA cable delay + ts2phc.extts_correction -10 + ptp4lConf: | + [$iface_timeTx1] + masterOnly 1 + [$iface_timeTx1_1] + masterOnly 1 + [$iface_timeTx1_2] + masterOnly 1 + [$iface_timeTx1_3] + masterOnly 1 + [$iface_timeTx2] + masterOnly 1 + [$iface_timeTx2_1] + masterOnly 1 + [$iface_timeTx2_2] + masterOnly 1 + [$iface_timeTx2_3] + masterOnly 1 + [$iface_timeTx3] + masterOnly 1 + [$iface_timeTx3_1] + masterOnly 1 + [$iface_timeTx3_2] + masterOnly 1 + [$iface_timeTx3_3] + masterOnly 1 + [global] + # + # Default Data Set + # + twoStepFlag 1 + priority1 128 + priority2 128 + domainNumber 24 + #utc_offset 37 + clockClass 6 + clockAccuracy 0x27 + offsetScaledLogVariance 0xFFFF + free_running 0 + freq_est_interval 1 + dscp_event 0 + dscp_general 0 + dataset_comparison G.8275.x + G.8275.defaultDS.localPriority 128 + # + # Port Data Set + # + logAnnounceInterval -3 + logSyncInterval -4 + logMinDelayReqInterval -4 + logMinPdelayReqInterval 0 + announceReceiptTimeout 3 + syncReceiptTimeout 0 + delayAsymmetry 0 + fault_reset_interval -4 + neighborPropDelayThresh 20000000 + masterOnly 0 + G.8275.portDS.localPriority 128 + # + # Run time options + # + assume_two_step 0 + logging_level 6 + path_trace_enabled 0 + follow_up_info 0 + hybrid_e2e 0 + inhibit_multicast_service 0 + net_sync_monitor 0 + tc_spanning_tree 0 + tx_timestamp_timeout 50 + unicast_listen 0 + unicast_master_table 0 + unicast_req_duration 3600 + use_syslog 1 + verbose 0 + summary_interval -4 + kernel_leap 1 + check_fup_sync 0 + clock_class_threshold 7 + # + # Servo Options + # + pi_proportional_const 0.0 + pi_integral_const 0.0 + pi_proportional_scale 0.0 + pi_proportional_exponent -0.3 + pi_proportional_norm_max 0.7 + pi_integral_scale 0.0 + pi_integral_exponent 0.4 + pi_integral_norm_max 0.3 + step_threshold 2.0 + first_step_threshold 0.00002 + clock_servo pi + sanity_freq_limit 200000000 + ntpshm_segment 0 + # + # Transport options + # + transportSpecific 0x0 + ptp_dst_mac 01:1B:19:00:00:00 + p2p_dst_mac 01:80:C2:00:00:0E + udp_ttl 1 + udp6_scope 0x0E + uds_address /var/run/ptp4l + # + # Default interface options + # + clock_type BC + network_transport L2 + delay_mechanism E2E + time_stamping hardware + tsproc_mode filter + delay_filter moving_median + delay_filter_length 10 + egressLatency 0 + ingressLatency 0 + boundary_clock_jbod 1 + # + # Clock description + # + productDescription ;; + revisionData ;; + manufacturerIdentity 00:00:00 + userDescription ; + timeSource 0x20 + ptpClockThreshold: + holdOverTimeout: 5 + maxOffsetThreshold: 1500 + minOffsetThreshold: -1500 + recommend: + - profile: grandmaster + priority: 4 + match: + - nodeLabel: node-role.kubernetes.io/$mcp \ No newline at end of file