E810 hardware plugin doc updates

WPC T-GM + GNSS updates General PTP docs reorg and clean up Updates based on Aneesh's review comments removing gnss-state-change from api/ocloudNotifications/v1/<resource_address>/CurrentState Adding metric details Adding new PTP image Adding final PTP 4.14 image Aneesh's comments jack's comments Adjust TOC Peer review comments
2026-02-05 12:46:18 +01:00 · 2023-09-28 13:14:50 +01:00
parent f55a1fe773
commit 8936b26f9e
84 changed files with 794 additions and 339 deletions
--- a/.vale/styles/Vocab/OpenShiftDocs/accept.txt
+++ b/.vale/styles/Vocab/OpenShiftDocs/accept.txt
@@ -1,20 +1,29 @@
 # Regex terms added to accept.txt are ignored by the Vale linter and override RedHat Vale rules.
 # Add terms that have a corresponding incorrectly capitalized form to reject.txt.
-
+# URL slugs
+(.*/)+
+(?<!.*-)operator
 [Ff]ronthaul
 [Mm]idhaul
 [Pp]assthrough
+[Pp]ostinstall
+[Pp]reinstall
 [Rr]ealtime
+[Tt]elco
 Assisted Installer
 Control Plane Machine Set Operator
-custom resource
-custom resources
+custom resources?
+gpsd
+gpspipe
+linuxptp
 Mbps
+Mellanox
 MetalLB
+NICs?
 Operator
 Operators
-[Pp]reinstall
-[Pp]ostinstall
-NICs?
-Mellanox
+Operators?
+pmc
+ubxtool
 VFs?
+Westport
--- a/.vale/styles/Vocab/OpenShiftDocs/reject.txt
+++ b/.vale/styles/Vocab/OpenShiftDocs/reject.txt
@@ -1,6 +1,7 @@
 # Regex terms added to reject.txt are highlighted as errors by the Vale linter and override RedHat Vale rules.
 # Add terms that have a corresponding correctly capitalized form to accept.txt.

+(?<!.*-)operators
 [Dd]eployment [Cc]onfigs?
 [Dd]eployment [Cc]onfigurations?
 [Oo]peratorize
@@ -11,5 +12,4 @@ configuration maps?
 MachineSets
 machinesets?
 minions?
-operators?
-SNO
+SNO
--- a/_topic_maps/_topic_map.yml
+++ b/_topic_maps/_topic_map.yml
@@ -1239,9 +1239,16 @@ Topics:
  File: using-sctp
  Distros: openshift-enterprise,openshift-origin
 - Name: Using PTP hardware
-  File: using-ptp
- Name: Developing PTP events consumer applications
-  File: ptp-cloud-events-consumer-dev-reference
+  Dir: ptp
+  Topics:
+  - Name: About PTP in OpenShift clusters
+    File: about-ptp
+  - Name: Configuring PTP hardware
+    File: configuring-ptp
+  - Name: Using PTP events
+    File: using-ptp-events
+  - Name: Developing PTP events consumer applications
+    File: ptp-cloud-events-consumer-dev-reference
 - Name: External DNS Operator
  Dir: external_dns_operator
  Topics:
--- a/authentication/sd-configuring-identity-providers.adoc
+++ b/authentication/sd-configuring-identity-providers.adoc
@@ -1,4 +1,4 @@
-:_content-type: ASSEMBLY
+:_mod-docs-content-type: ASSEMBLY
 [id="sd-configuring-identity-providers"]
 = Configuring identity providers
 include::_attributes/attributes-openshift-dedicated.adoc[]
--- a/images/319_OpenShift_PTP_bare-metal_OCP_nodes_1023_PTP.png
+++ b/images/319_OpenShift_PTP_bare-metal_OCP_nodes_1023_PTP.png
--- a/images/319_OpenShift_PTP_bare-metal_OCP_nodes_1123_PTP_network.png
+++ b/images/319_OpenShift_PTP_bare-metal_OCP_nodes_1123_PTP_network.png
--- a/modules/cnf-about-collecting-ptp-data.adoc
+++ b/modules/cnf-about-collecting-ptp-data.adoc
@@ -1,12 +1,12 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="cnf-about-collecting-nro-data_{context}"]
-= Collecting Precision Time Protocol (PTP) Operator data
+= Collecting PTP Operator data

-You can use the `oc adm must-gather` CLI command to collect information about your cluster, including features and objects associated with Precision Time Protocol (PTP) Operator.
+You can use the `oc adm must-gather` command to collect information about your cluster, including features and objects associated with PTP Operator.

 .Prerequisites

@@ -23,4 +23,4 @@ You can use the `oc adm must-gather` CLI command to collect information about yo
 [source,terminal,subs="attributes+"]
 ----
 $ oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel8:v{product-version}
----
+----
--- a/modules/cnf-about-ptp-and-clock-synchronization.adoc
+++ b/modules/cnf-about-ptp-and-clock-synchronization.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/using-ptp-events.adoc

 :_mod-docs-content-type: CONCEPT
 [id="cnf-about-ptp-and-clock-synchronization_{context}"]
@@ -8,7 +8,7 @@

 Loss of PTP synchronization is a critical error for a RAN network. If synchronization is lost on a node, the radio might be shut down and the network Over the Air (OTA) traffic might be shifted to another node in the wireless network. Fast event notifications mitigate against workload errors by allowing cluster nodes to communicate PTP clock sync status to the vRAN application running in the DU.

-Event notifications are available to vRAN applications running on the same DU node. A publish-subscribe REST API passes events notifications to the messaging bus. Publish-subscribe messaging, or pub-sub messaging, is an asynchronous service-to-service communication architecture where any message published to a topic is immediately received by all of the subscribers to the topic.
+Event notifications are available to vRAN applications running on the same DU node. A publish/subscribe REST API passes events notifications to the messaging bus. Publish/subscribe messaging, or pub-sub messaging, is an asynchronous service-to-service communication architecture where any message published to a topic is immediately received by all of the subscribers to the topic.

 The PTP Operator generates fast event notifications for every PTP-capable network interface. You can access the events by using a `cloud-event-proxy` sidecar container over an HTTP or Advanced Message Queuing Protocol (AMQP) message bus.

--- a/modules/cnf-about-ptp-fast-event-notifications-framework.adoc
+++ b/modules/cnf-about-ptp-fast-event-notifications-framework.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/using-ptp-events.adoc

 :_mod-docs-content-type: CONCEPT
 [id="cnf-about-ptp-fast-event-notifications-framework_{context}"]
--- a/modules/cnf-configuring-fifo-priority-scheduling-for-ptp.adoc
+++ b/modules/cnf-configuring-fifo-priority-scheduling-for-ptp.adoc
@@ -1,12 +1,12 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="cnf-configuring-fifo-priority-scheduling-for-ptp_{context}"]
 = Configuring FIFO priority scheduling for PTP hardware

-In telco or other deployment configurations that require low latency performance, PTP daemon threads run in a constrained CPU footprint alongside the rest of the infrastructure components. By default, PTP threads run with the `SCHED_OTHER` policy. Under high load, these threads might not get the scheduling latency they require for error-free operation.
+In telco or other deployment types that require low latency performance, PTP daemon threads run in a constrained CPU footprint alongside the rest of the infrastructure components. By default, PTP threads run with the `SCHED_OTHER` policy. Under high load, these threads might not get the scheduling latency they require for error-free operation.

 To mitigate against potential scheduling latency errors, you can configure the PTP Operator `linuxptp` services to allow threads to run with a `SCHED_FIFO` policy. If `SCHED_FIFO` is set for a `PtpConfig` CR, then `ptp4l` and `phc2sys` will run in the parent container under `chrt` with a priority set by the `ptpSchedulingPriority` field of the `PtpConfig` CR.

@@ -76,5 +76,3 @@ $ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|gr
 ----
 I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2  --summary_interval -4 -m
 ----
-
-
--- a/modules/cnf-configuring-log-filtering-for-linuxptp.adoc
+++ b/modules/cnf-configuring-log-filtering-for-linuxptp.adoc
@@ -1,12 +1,12 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="cnf-configuring-log-filtering-for-linuxptp_{context}"]
 = Configuring log filtering for linuxptp services

-The `linuxptp` daemon generates logs that you can use for debugging purposes. In telco or other deployment configurations that feature a limited storage capacity, these logs can add to the storage demand.
+The `linuxptp` daemon generates logs that you can use for debugging purposes. In telco or other deployment types that feature a limited storage capacity, these logs can add to the storage demand.

 To reduce the number log messages, you can configure the `PtpConfig` custom resource (CR) to exclude log messages that report the `master offset` value. The `master offset` log message reports the difference between the current node's clock and the master clock in nanoseconds.

@@ -77,4 +77,4 @@ $ oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container
 ----
 <1> <linux_daemon_container> is the name of the `linuxptp-daemon` pod, for example `linuxptp-daemon-gmv2n`.
 +
-When you configure the `logReduce` specification, this command does not report any instances of `master offset` in the logs of the `linuxptp` daemon.
+When you configure the `logReduce` specification, this command does not report any instances of `master offset` in the logs of the `linuxptp` daemon.
--- a/modules/cnf-configuring-the-ptp-fast-event-publisher.adoc
+++ b/modules/cnf-configuring-the-ptp-fast-event-publisher.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/using-ptp-events.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="cnf-configuring-the-ptp-fast-event-publisher_{context}"]
--- a/modules/cnf-fast-event-notifications-api-refererence.adoc
+++ b/modules/cnf-fast-event-notifications-api-refererence.adoc
@@ -1,39 +1,14 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/using-ptp-events.adoc

+:_mod-docs-content-type: PROCEDURE
 [id="cnf-fast-event-notifications-api-refererence_{context}"]
-= Subscribing DU applications to PTP events REST API reference
+= PTP events REST API reference

-Use the PTP event notifications REST API to subscribe a distributed unit (DU) application to the PTP events that are generated on the parent node.
-
-Subscribe applications to PTP events by using the resource address `/cluster/node/<node_name>/ptp`, where `<node_name>` is the cluster node running the DU application.
-
-Deploy your `cloud-event-consumer` DU application container and `cloud-event-proxy` sidecar container in a separate DU application pod. The `cloud-event-consumer` DU application subscribes to the `cloud-event-proxy` container in the application pod.
-
-Use the following API endpoints to subscribe the `cloud-event-consumer` DU application to PTP events posted by the `cloud-event-proxy` container at [x-]`http://localhost:8089/api/ocloudNotifications/v1/` in the DU application pod:
-
-* `/api/ocloudNotifications/v1/subscriptions`
- `POST`: Creates a new subscription
- `GET`: Retrieves a list of subscriptions
-
-* `/api/ocloudNotifications/v1/subscriptions/<subscription_id>`
- `GET`: Returns details for the specified subscription ID
-
-* `/api/ocloudNotifications/v1/health`
- `GET`: Returns the health status of `ocloudNotifications` API
-
-* `api/ocloudNotifications/v1/publishers`
- `GET`: Returns an array of `os-clock-sync-state`, `ptp-clock-class-change`, and `lock-state` messages for the cluster node
-
-* `/api/ocloudnotifications/v1/<resource_address>/CurrentState`
-  `GET`: Returns the current state of one the following event types: `os-clock-sync-state`, `ptp-clock-class-change`, or `lock-state` events
-
-[NOTE]
-====
-`9089` is the default port for the `cloud-event-consumer` container deployed in the application pod. You can configure a different port for your DU application as required.
-====
+Use the PTP event notifications REST API to subscribe a cluster application to the PTP events that are generated on the parent node.

+[id="api-ocloud-notifications-v1-subscriptions_{context}"]
 == api/ocloudNotifications/v1/subscriptions

 [discrete]
@@ -42,7 +17,7 @@ Use the following API endpoints to subscribe the `cloud-event-consumer` DU appli
 `GET api/ocloudNotifications/v1/subscriptions`

 [discrete]
-==== Description
+=== Description

 Returns a list of subscriptions. If subscriptions exist, a `200 OK` status code is returned along with the list of subscriptions.

@@ -65,17 +40,19 @@ Returns a list of subscriptions. If subscriptions exist, a `200 OK` status code
 `POST api/ocloudNotifications/v1/subscriptions`

 [discrete]
-==== Description
+=== Description

 Creates a new subscription. If a subscription is successfully created, or if it already exists, a `201 Created` status code is returned.

 .Query parameters
-|===
-| Parameter | Type
+[cols=2*, width="60%", options="header"]
+|====
+|Parameter
+|Type

-| subscription
-| data
-|===
+|subscription
+|data
+|====

 .Example payload
 [source,json]
@@ -86,6 +63,7 @@ Creates a new subscription. If a subscription is successfully created, or if it
 }
 ----

+[id="api-ocloud-notifications-v1-subscriptions-subscription_id_{context}"]
 == api/ocloudNotifications/v1/subscriptions/<subscription_id>

 [discrete]
@@ -94,17 +72,19 @@ Creates a new subscription. If a subscription is successfully created, or if it
 `GET api/ocloudNotifications/v1/subscriptions/<subscription_id>`

 [discrete]
-==== Description
+=== Description

 Returns details for the subscription with ID `<subscription_id>`

 .Query parameters
-|===
-| Parameter | Type
+[cols=2*, width="60%", options="header"]
+|====
+|Parameter
+|Type

-| `<subscription_id>`
-| string
-|===
+|`<subscription_id>`
+|string
+|====

 .Example API response
 [source,json]
@@ -117,7 +97,8 @@ Returns details for the subscription with ID `<subscription_id>`
 }
 ----

-== api/ocloudNotifications/v1/health/
+[id="api-ocloudnotifications-v1-health_{context}"]
+== api/ocloudNotifications/v1/health

 [discrete]
 === HTTP method
@@ -125,7 +106,7 @@ Returns details for the subscription with ID `<subscription_id>`
 `GET api/ocloudNotifications/v1/health/`

 [discrete]
-==== Description
+=== Description

 Returns the health status for the `ocloudNotifications` REST API.

@@ -135,6 +116,7 @@ Returns the health status for the `ocloudNotifications` REST API.
 OK
 ----

+[id="api-ocloudnotifications-v1-publishers_{context}"]
 == api/ocloudNotifications/v1/publishers

 [discrete]
@@ -143,13 +125,17 @@ OK
 `GET api/ocloudNotifications/v1/publishers`

 [discrete]
-==== Description
+=== Description

-Returns an array of `os-clock-sync-state`, `ptp-clock-class-change`, and `lock-state` details for the cluster node. The system generates notifications when the relevant equipment state changes.
+Returns an array of `os-clock-sync-state`, `ptp-clock-class-change`, `lock-state`, and `gnss-sync-status` details for the cluster node.
+The system generates notifications when the relevant equipment state changes.

 * `os-clock-sync-state` notifications describe the host operating system clock synchronization state. Can be in `LOCKED` or `FREERUN` state.
 * `ptp-clock-class-change` notifications describe the current state of the PTP clock class.
 * `lock-state` notifications describe the current status of the PTP equipment lock state. Can be in `LOCKED`, `HOLDOVER` or `FREERUN` state.
+* `gnss-sync-status` notifications describe the GPS synchronization state with regard to the external GNSS clock signal. Can be in `LOCKED` or `FREERUN` state.
+
+You can use equipment synchronization status subscriptions together to deliver a detailed view of the overall synchronization health of the system.

 .Example API response
 [source,json]
@@ -172,11 +158,17 @@ Returns an array of `os-clock-sync-state`, `ptp-clock-class-change`, and `lock-s
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state"
+  },
+  {
+    "id": "778da345d-4567-67b0-a43f0-rty885a456",
+    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
+    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/778da345d-4567-67b0-a43f0-rty885a456",
+    "resource": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status"
  }
 ]
 ----

-You can find `os-clock-sync-state`, `ptp-clock-class-change` and `lock-state` events in the logs for the `cloud-event-proxy` container. For example:
+You can find `os-clock-sync-state`, `ptp-clock-class-change`, `lock-state`, and `gnss-sync-status` events in the logs for the `cloud-event-proxy` container. For example:

 [source,terminal]
 ----
@@ -264,7 +256,37 @@ $ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
 }
 ----

-== /api/ocloudnotifications/v1/<resource_address>/CurrentState
+.Example gnss-sync-status event
+[source,json]
+----
+{
+  "id": "435e1f2a-6854-4555-8520-767325c087d7",
+  "type": "event.sync.gnss-status.gnss-state-change",
+  "source": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status",
+  "dataContentType": "application/json",
+  "time": "2023-09-27T19:35:33.42347206Z",
+  "data": {
+    "version": "v1",
+    "values": [
+      {
+        "resource": "/cluster/node/compute-1.example.com/ens2fx/master",
+        "dataType": "notification",
+        "valueType": "enumeration",
+        "value": "LOCKED"
+      },
+      {
+        "resource": "/cluster/node/compute-1.example.com/ens2fx/master",
+        "dataType": "metric",
+        "valueType": "decimal64.3",
+        "value": "5"
+      }
+    ]
+  }
+}
+----
+
+[id="resource-address-current-state_{context}"]
+== api/ocloudNotifications/v1/<resource_address>/CurrentState

 [discrete]
 === HTTP method
@@ -276,21 +298,23 @@ $ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
 `GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change/CurrentState`

 [discrete]
-==== Description
+=== Description

-Configure the `CurrentState` API endpoint to return the current state of the `os-clock-sync-state`, `ptp-clock-class-change`, or `lock-state` events for the cluster node.
+Configure the `CurrentState` API endpoint to return the current state of the `os-clock-sync-state`, `ptp-clock-class-change`, `lock-state` events for the cluster node.

 * `os-clock-sync-state` notifications describe the host operating system clock synchronization state. Can be in `LOCKED` or `FREERUN` state.
 * `ptp-clock-class-change` notifications describe the current state of the PTP clock class.
 * `lock-state` notifications describe the current status of the PTP equipment lock state. Can be in `LOCKED`, `HOLDOVER` or `FREERUN` state.

 .Query parameters
-|===
-| Parameter | Type
+[cols=2*, width="60%", options="header"]
+|====
+|Parameter
+|Type

-| `<resource_address>`
-| string
-|===
+|`<resource_address>`
+|string
+|====

 .Example lock-state API response
 [source,json]
--- a/modules/cnf-installing-amq-interconnect-messaging-bus.adoc
+++ b/modules/cnf-installing-amq-interconnect-messaging-bus.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/using-ptp-events.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="cnf-installing-amq-interconnect-messaging-bus_{context}"]
--- a/modules/cnf-migrating-from-amqp-to-http-transport.adoc
+++ b/modules/cnf-migrating-from-amqp-to-http-transport.adoc
@@ -1,7 +1,7 @@
 // Module included in the following assemblies:
 //
 // * monitoring/using-rfhe.adoc
-// * networking/using-ptp.adoc
+// * networking/ptp/using-ptp-events.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="cnf-migrating-from-amqp-to-http-transport_{context}"]
--- a/modules/cnf-monitoring-fast-events-metrics.adoc
+++ b/modules/cnf-monitoring-fast-events-metrics.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/using-ptp-events.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="cnf-monitoring-fast-events-metrics_{context}"]
@@ -19,35 +19,28 @@ You can also monitor PTP fast event metrics in the {product-title} web console b

 .Procedure

-. Check for exposed PTP metrics on any node where the `linuxptp-daemon` is running. For example, run the following command:
+. Start a debug pod for the node by running the following command:
 +
 [source,terminal]
 ----
-$ curl http://<node_name>:9091/metrics
+$ oc debug node/<node_name>
+----
+
+. Check for PTP metrics exposed by the `linuxptp-daemon` container. For example, run the following command:
+
+[source,terminal]
+----
+sh-4.4# curl http://localhost:9091/metrics
 ----
 +
 .Example output
 ----
-# HELP openshift_ptp_clock_state 0 = FREERUN, 1 = LOCKED, 2 = HOLDOVER
-# TYPE openshift_ptp_clock_state gauge
-openshift_ptp_clock_state{iface="ens1fx",node="compute-1.example.com",process="ptp4l"} 1
-openshift_ptp_clock_state{iface="ens3fx",node="compute-1.example.com",process="ptp4l"} 1
-openshift_ptp_clock_state{iface="ens5fx",node="compute-1.example.com",process="ptp4l"} 1
-openshift_ptp_clock_state{iface="ens7fx",node="compute-1.example.com",process="ptp4l"} 1
-# HELP openshift_ptp_delay_ns
-# TYPE openshift_ptp_delay_ns gauge
-openshift_ptp_delay_ns{from="master",iface="ens1fx",node="compute-1.example.com",process="ptp4l"} 842
-openshift_ptp_delay_ns{from="master",iface="ens3fx",node="compute-1.example.com",process="ptp4l"} 480
-openshift_ptp_delay_ns{from="master",iface="ens5fx",node="compute-1.example.com",process="ptp4l"} 584
-openshift_ptp_delay_ns{from="master",iface="ens7fx",node="compute-1.example.com",process="ptp4l"} 482
-openshift_ptp_delay_ns{from="phc",iface="CLOCK_REALTIME",node="compute-1.example.com",process="phc2sys"} 547
-# HELP openshift_ptp_offset_ns
-# TYPE openshift_ptp_offset_ns gauge
-openshift_ptp_offset_ns{from="master",iface="ens1fx",node="compute-1.example.com",process="ptp4l"} -2
-openshift_ptp_offset_ns{from="master",iface="ens3fx",node="compute-1.example.com",process="ptp4l"} -44
-openshift_ptp_offset_ns{from="master",iface="ens5fx",node="compute-1.example.com",process="ptp4l"} -8
-openshift_ptp_offset_ns{from="master",iface="ens7fx",node="compute-1.example.com",process="ptp4l"} 3
-openshift_ptp_offset_ns{from="phc",iface="CLOCK_REALTIME",node="compute-1.example.com",process="phc2sys"} 12
+# HELP cne_api_events_published Metric to get number of events published by the rest api
+# TYPE cne_api_events_published gauge
+cne_api_events_published{address="/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status",status="success"} 1
+cne_api_events_published{address="/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",status="success"} 94
+cne_api_events_published{address="/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",status="success"} 18
+cne_api_events_published{address="/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",status="success"} 27
 ----

 . To view the PTP event in the {product-title} web console, copy the name of the PTP metric you want to query, for example, `openshift_ptp_offset_ns`.
--- a/modules/cnf-troubleshooting-common-ptp-operator-issues.adoc
+++ b/modules/cnf-troubleshooting-common-ptp-operator-issues.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="cnf-troubleshooting-common-ptp-operator-issues_{context}"]
@@ -141,3 +141,37 @@ sending: GET PORT_DATA_SET
        logMinPdelayReqInterval -4
        versionNumber           2
 ----
+
+. For GNSS-sourced grandmaster clocks, verify that the in-tree NIC ice driver is correct by running the following command, for example:
+
+[source,terminal]
+----
+$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-74m2g ethtool -i ens7f0
+----
+
+.Example output
+[source,terminal]
+----
+driver: ice
+version: 5.14.0-356.bz2232515.el9.x86_64
+firmware-version: 4.20 0x8001778b 1.3346.0
+----
+
+. For GNSS-sourced grandmaster clocks, verify that the `linuxptp-daemon` container is receiving signal from the GNSS antenna.
+If the container is not receiving the GNSS signal, the `/dev/gnss0` file is not populated.
+To verify, run the following command:
+
+[source,terminal]
+----
+$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-jnz6r cat /dev/gnss0
+----
+
+.Example output
+[source,terminal]
+----
+$GNRMC,125223.00,A,4233.24463,N,07126.64561,W,0.000,,300823,,,A,V*0A
+$GNVTG,,T,,M,0.000,N,0.000,K,A*3D
+$GNGGA,125223.00,4233.24463,N,07126.64561,W,1,12,99.99,98.6,M,-33.1,M,,*7E
+$GNGSA,A,3,25,17,19,11,12,06,05,04,09,20,,,99.99,99.99,99.99,1*37
+$GPGSV,3,1,10,04,12,039,41,05,31,222,46,06,50,064,48,09,28,064,42,1*62
+----
--- a/modules/hosted-cluster-etcd-quorum-loss-recovery.adoc
+++ b/modules/hosted-cluster-etcd-quorum-loss-recovery.adoc
@@ -2,7 +2,7 @@
 //
 // * hcp-backup-restore-dr.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="hosted-cluster-etcd-quorum-loss-recovery_{context}"]
 = Recovering an etcd cluster from a quorum loss

@@ -87,7 +87,7 @@ $ ETCD_POD=etcd-0
 ----
 +
 [source,terminal]
---- 
+----
 $ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- env ETCDCTL_API=3 /usr/bin/etcdctl \
 --cacert /etc/etcd/tls/etcd-ca/ca.crt \
 --cert /etc/etcd/tls/client/etcd-client.crt \
@@ -116,7 +116,7 @@ $ oc cp -c etcd ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/snapshot.db /tmp
 +
 [source,terminal]
 ----
-$ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd 
+$ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd
 ----

 .... Find a pod that is running and set its name as the value of `ETCD_POD: ETCD_POD=etcd-0`, and then copy its snapshot database by entering the following command:
--- a/modules/installation-user-infra-machines-advanced-customizing-live-ca-certs.adoc
+++ b/modules/installation-user-infra-machines-advanced-customizing-live-ca-certs.adoc
@@ -4,7 +4,7 @@
 // * installing/installing_bare_metal/installing-restricted-networks-bare-metal.adoc
 // * installing_bare_metal/installing-bare-metal-network-customizations.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="installation-user-infra-machines-advanced-customizing-live-{boot}-ca-certs_{context}"]
 = Modifying a live install {boot-media} to use a custom certificate authority

--- a/modules/installation-user-infra-machines-advanced-customizing-live-network-config.adoc
+++ b/modules/installation-user-infra-machines-advanced-customizing-live-network-config.adoc
@@ -4,7 +4,7 @@
 // * installing/installing_bare_metal/installing-restricted-networks-bare-metal.adoc
 // * installing_bare_metal/installing-bare-metal-network-customizations.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="installation-user-infra-machines-advanced-customizing-live-{boot}_network_keyfile_{context}"]
 = Modifying a live install {boot-media} with customized network settings
 You can embed a NetworkManager keyfile into the live {boot-media} and pass it through to the installed system with the `--network-keyfile` flag of the `customize` subcommand.
--- a/modules/installation-user-infra-machines-advanced-customizing-live.adoc
+++ b/modules/installation-user-infra-machines-advanced-customizing-live.adoc
@@ -4,7 +4,7 @@
 // * installing/installing_bare_metal/installing-restricted-networks-bare-metal.adoc
 // * installing_bare_metal/installing-bare-metal-network-customizations.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="installation-user-infra-machines-advanced-customizing-live-{boot}_{context}"]
 = Customizing a live {op-system} {boot-media}
 You can customize a live {op-system} {boot-media} directly with the
--- a/modules/kmm-hub-hub-and-spoke.adoc
+++ b/modules/kmm-hub-hub-and-spoke.adoc
@@ -2,7 +2,7 @@
 //
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="kmm-hub-hub-and-spoke_{context}"]
 = KMM hub and spoke

--- a/modules/kmm-hub-installing-kmm-hub-creating-resources.adoc
+++ b/modules/kmm-hub-installing-kmm-hub-creating-resources.adoc
@@ -2,7 +2,7 @@
 //
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="kmm-hub-installing-kmm-hub-creating-resources_{context}"]
 = Installing KMM-Hub by creating KMM resources

--- a/modules/kmm-hub-installing-kmm-hub-olm.adoc
+++ b/modules/kmm-hub-installing-kmm-hub-olm.adoc
@@ -2,7 +2,7 @@
 //
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="kmm-hub-installing-kmm-hub-olm_{context}"]
 = Installing KMM-Hub using the Operator Lifecycle Manager

--- a/modules/kmm-hub-installing-kmm-hub.adoc
+++ b/modules/kmm-hub-installing-kmm-hub.adoc
@@ -2,7 +2,7 @@
 //
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="kmm-hub-installing-kmm-hub_{context}"]
 = Installing KMM-Hub

--- a/modules/kmm-hub-kmm-hub.adoc
+++ b/modules/kmm-hub-kmm-hub.adoc
@@ -2,7 +2,7 @@
 //
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="kmm-hub-kmm-hub_{context}"]
 = KMM-Hub

--- a/modules/kmm-hub-running-kmm-on-the-spoke.adoc
+++ b/modules/kmm-hub-running-kmm-on-the-spoke.adoc
@@ -2,7 +2,7 @@
 //
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="kmm-hub-running-kmm-on-the-spoke_{context}"]
 = Running KMM on the spoke

--- a/modules/kmm-hub-using-the-managedclustermodule.adoc
+++ b/modules/kmm-hub-using-the-managedclustermodule.adoc
@@ -2,7 +2,7 @@
 //
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="kmm-hub-using-the-managedclustermodule_{context}"]
 = Using the `ManagedClusterModule` CRD

--- a/modules/kmm-uninstalling-kmm.adoc
+++ b/modules/kmm-uninstalling-kmm.adoc
@@ -2,7 +2,7 @@
 //
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="kmm-uninstalling-kmmo_{context}"]
 = Uninstalling the Kernel Module Management Operator

--- a/modules/kmm-uninstalling-kmmo-cli.adoc
+++ b/modules/kmm-uninstalling-kmmo-cli.adoc
@@ -1,6 +1,6 @@
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="kmm-uninstalling-kmmo-cli_{context}"]
 = Uninstalling a CLI installation

--- a/modules/kmm-uninstalling-kmmo-red-hat-catalog.adoc
+++ b/modules/kmm-uninstalling-kmmo-red-hat-catalog.adoc
@@ -1,6 +1,6 @@
 // * hardware_enablement/kmm-kernel-module-management.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="kmm-uninstalling-kmmo-red-hat-catalog_{context}"]
 = Uninstalling a Red Hat catalog installation

--- a/modules/log-forwarding-implementations.adoc
+++ b/modules/log-forwarding-implementations.adoc
@@ -2,7 +2,7 @@
 //
 // * logging/log_collection_forwarding/log-forwarding.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="log-forwarding-implementations_{context}"]
 = Log forwarding implementations

--- a/modules/logging-loki-log-access.adoc
+++ b/modules/logging-loki-log-access.adoc
@@ -2,7 +2,7 @@
 //
 // * logging/cluster-logging-loki.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="logging-loki-log-access_{context}"]
 = Fine grained access for Loki logs
 In {logging} 5.8 and later, the ClusterLogging Operator does not grant all users access to logs by default.  As an administrator, you need to configure your users access unless the Operator was upgraded and prior configurations are in place. Depending on your configuration and need, you can configure fine grain access to logs using the following:
--- a/modules/logging-upgrading-loki.adoc
+++ b/modules/logging-upgrading-loki.adoc
@@ -2,7 +2,7 @@
 //
 // * logging/cluster-logging-upgrading.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="logging-upgrading-loki_{context}"]
 = Updating the Loki Operator

--- a/modules/nodes-pods-secrets-creating-web-console-secrets.adoc
+++ b/modules/nodes-pods-secrets-creating-web-console-secrets.adoc
@@ -2,17 +2,17 @@
 //
 // * nodes/pods/nodes-pods-secrets.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="nodes-pods-secrets-creating-web-console-secrets_{context}"]
 = Creating a secret using the web console

-You can create secrets using the web console. 
+You can create secrets using the web console.

 .Procedure

 . Navigate to *Workloads* -> *Secrets*.
 . Click *Create* -> *From YAML*.
-.. Edit the YAML manually to your specifications, or drag and drop a file into the YAML editor. 
+.. Edit the YAML manually to your specifications, or drag and drop a file into the YAML editor.
 For example:
 +
 [source,yaml]
@@ -27,13 +27,12 @@ data:
  username: <base64 encoded username>
  password: <base64 encoded password>
 stringData: <2>
-  hostname: myapp.mydomain.com 
+  hostname: myapp.mydomain.com
 ----
-<1> This example specifies an opaque secret; however, you may see other secret types such as service account token secret, basic authentication secret, SSH authentication secret, or a secret that uses Docker configuration. 
+<1> This example specifies an opaque secret; however, you may see other secret types such as service account token secret, basic authentication secret, SSH authentication secret, or a secret that uses Docker configuration.
 <2> Entries in the `stringData` map are converted to base64 and the entry will then be moved to the `data` map automatically. This field is write-only; the value will only be returned via the `data` field.

 . Click *Create*.
 . Click *Add Secret to workload*.
 .. From the drop-down menu, select the workload to add.
 .. Click *Save*.
-
--- a/modules/nvidia-gpu-cuda-mps.adoc
+++ b/modules/nvidia-gpu-cuda-mps.adoc
@@ -2,7 +2,7 @@
 //
 // * architecture/nvidia-gpu-architecture-overview.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="nvidia-gpu-cuda-mps_{context}"]
 = CUDA Multi-Process Service

--- a/modules/nvidia-gpu-cuda-streams.adoc
+++ b/modules/nvidia-gpu-cuda-streams.adoc
@@ -2,7 +2,7 @@
 //
 // * architecture/nvidia-gpu-architecture-overview.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="nvidia-gpu-cuda-streams_{context}"]
 = CUDA streams

--- a/modules/nvidia-gpu-mig-gpu.adoc
+++ b/modules/nvidia-gpu-mig-gpu.adoc
@@ -2,7 +2,7 @@
 //
 // * architecture/nvidia-gpu-architecture-overview.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="nvidia-gpu-mig-gpu_{context}"]
 = Multi-instance GPU

--- a/modules/nvidia-gpu-sharing-methods.adoc
+++ b/modules/nvidia-gpu-sharing-methods.adoc
@@ -2,7 +2,7 @@
 //
 // * architecture/nvidia-gpu-architecture-overview.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="nvidia-gpu-sharing-methods_{context}"]
 = GPU sharing methods

--- a/modules/nvidia-gpu-time-slicing.adoc
+++ b/modules/nvidia-gpu-time-slicing.adoc
@@ -2,7 +2,7 @@
 //
 // * architecture/nvidia-gpu-architecture-overview.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="nvidia-gpu-time-slicing_{context}"]
 = Time-slicing

--- a/modules/nvidia-gpu-virtualization-with-gpu.adoc
+++ b/modules/nvidia-gpu-virtualization-with-gpu.adoc
@@ -2,7 +2,7 @@
 //
 // * architecture/nvidia-gpu-architecture-overview.adoc

-:_content-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="nvidia-gpu-virtualization-with-gpu_{context}"]
 = Virtualization with vGPU

--- a/modules/nw-columbiaville-ptp-config-refererence.adoc
+++ b/modules/nw-columbiaville-ptp-config-refererence.adoc
@@ -1,12 +1,12 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: REFERENCE
 [id="nw-columbiaville-ptp-config-refererence_{context}"]
 = Intel Columbiaville E800 series NIC as PTP ordinary clock reference

-The following table describes the changes that you must make to the reference PTP configuration in order to use Intel Columbiaville E800 series NICs as ordinary clocks. Make the changes in a `PtpConfig` custom resource (CR) that you apply to the cluster.
+The following table describes the changes that you must make to the reference PTP configuration to use Intel Columbiaville E800 series NICs as ordinary clocks. Make the changes in a `PtpConfig` custom resource (CR) that you apply to the cluster.

 .Recommended PTP settings for Intel Columbiaville NIC
 [options="header"]
@@ -21,6 +21,3 @@ The following table describes the changes that you must make to the reference PT
 ====
 For `phc2sysOpts`, `-m` prints messages to `stdout`. The `linuxptp-daemon` `DaemonSet` parses the logs and generates Prometheus metrics.
 ====
-
-
-
--- a/modules/nw-ptp-configuring-linuxptp-services-as-boundary-clock.adoc
+++ b/modules/nw-ptp-configuring-linuxptp-services-as-boundary-clock.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="configuring-linuxptp-services-as-boundary-clock_{context}"]
@@ -37,7 +37,7 @@ include::snippets/ptp_PtpConfigBoundary.yaml[]
 .PTP boundary clock CR configuration options
 [cols="1,3" options="header"]
 |====
-|Custom resource field
+|CR field
 |Description

 |`name`
--- a/modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock.adoc
+++ b/modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock.adoc
@@ -1,19 +1,20 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="configuring-linuxptp-services-as-grandmaster-clock_{context}"]
 = Configuring linuxptp services as a grandmaster clock

-You can configure the `linuxptp` services (`ptp4l`, `phc2sys`, `ts2phc`) as a grandmaster clock (T-GM) by creating a `PtpConfig` custom resource (CR) that configures the host NIC.
+You can configure the `linuxptp` services (`ptp4l`, `phc2sys`, `ts2phc`) as grandmaster clock (T-GM) by creating a `PtpConfig` custom resource (CR) that configures the host NIC.

 The `ts2phc` utility allows you to synchronize the system clock with the PTP grandmaster clock so that the node can stream precision clock signal to downstream PTP ordinary clocks and boundary clocks.

 [NOTE]
 ====
-Use the following example `PtpConfig` CR as the basis to configure `linuxptp` services as the grandmaster clock for your particular hardware and environment.
-This example CR does not configure PTP fast events. To configure PTP fast events, set appropriate values for `ptp4lOpts`, `ptp4lConf`, and `ptpClockThreshold`.
+Use the following example `PtpConfig` CR as the basis to configure `linuxptp` services as T-GM for an Intel Westport Channel E810-XXVDA4T network interface.
+
+To configure PTP fast events, set appropriate values for `ptp4lOpts`, `ptp4lConf`, and `ptpClockThreshold`.
 `ptpClockThreshold` is used only when events are enabled.
 See "Configuring the PTP fast event notifications publisher" for more information.
 ====
@@ -30,7 +31,7 @@ See "Configuring the PTP fast event notifications publisher" for more informatio

 .Procedure

-. Create the `PtpConfig` resource. For example:
+. Create the `PtpConfig` CR. For example:

 .. Depending on your requirements, use one of the following T-GM configurations for your deployment.
 Save the YAML in the `grandmaster-clock-ptp-config.yaml` file:
@@ -40,7 +41,7 @@ Save the YAML in the `grandmaster-clock-ptp-config.yaml` file:
 =====
 [source,yaml]
 ----
-include::snippets/ptp_PtpConfigMaster.yaml[]
+include::snippets/ptp_PtpConfigGmWpc.yaml[]
 ----

 [NOTE]
@@ -57,6 +58,11 @@ The example PTP grandmaster clock configuration is for test purposes only and is
 include::snippets/ptp_PtpConfigGmWpc.yaml[]
 ----
 ====
+
+[NOTE]
+====
+For E810 Westport Channel NICs, set the value for `ts2phc.nmea_serialport` to `/dev/gnss0`.
+====

 .. Create the CR by running the following command:
 +
--- a/modules/nw-ptp-configuring-linuxptp-services-as-ordinary-clock.adoc
+++ b/modules/nw-ptp-configuring-linuxptp-services-as-ordinary-clock.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="configuring-linuxptp-services-as-ordinary-clock_{context}"]
@@ -36,7 +36,7 @@ include::snippets/ptp_PtpConfigOrdinaryClock.yaml[]
 .PTP ordinary clock CR configuration options
 [cols="1,3" options="header"]
 |====
-|Custom resource field
+|CR field
 |Description

 |`name`
--- a/modules/nw-ptp-device-discovery.adoc
+++ b/modules/nw-ptp-device-discovery.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="discover-ptp-devices_{context}"]
@@ -40,4 +40,3 @@ items:
 ----
 <1> The value for the `name` parameter is the same as the name of the parent node.
 <2> The `devices` collection includes a list of the PTP capable devices that the PTP Operator discovers for the node.
-
--- a/modules/nw-ptp-e810-hardware-configuration-reference.adoc
+++ b/modules/nw-ptp-e810-hardware-configuration-reference.adoc
@@ -0,0 +1,100 @@
+// Module included in the following assemblies:
+//
+// * networking/ptp/configuring-ptp.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="nw-ptp-wpc-hardware-pins-reference_{context}"]
+= Intel Westport Channel E810 hardware configuration reference
+
+Use this information to understand how to use the link:https://github.com/openshift/linuxptp-daemon/blob/release-4.14/addons/intel/e810.go[Intel E810-XXVDA4T hardware plugin] to configure the E810 network interface as PTP grandmaster clock.
+Hardware pin configuration determines how the network interface interacts with other components and devices in the system.
+The E810-XXVDA4T NIC has four connectors for external 1PPS signals: `SMA1`, `SMA2`, `U.FL1`, and `U.FL2`.
+
+.Intel E810 NIC hardware connectors configuration
+[width="90%", options="header"]
+|====
+|Hardware pin|Recommended setting|Description
+|`U.FL1`|`0 1`|Disables the `U.FL1` connector input.
+The `U.FL1` connector is output-only.
+|`U.FL2`|`0 2`|Disables the `U.FL2` connector output.
+The `U.FL2` connector is input-only.
+|`SMA1`|`0 1`|Disables the `SMA1` connector input.
+The `SMA1` connector is bidirectional.
+|`SMA2`|`0 2`|Disables the `SMA2` connector output.
+The `SMA2` connector is bidirectional.
+|====
+
+[NOTE]
+====
+`SMA1` and `U.FL1` connectors share channel one.
+`SMA2` and `U.FL2` connectors share channel two.
+====
+
+Set `spec.profile.plugins.e810.ublxCmds` parameters to configure the GNSS clock in the `PtpConfig` custom resource (CR).
+Each of these `ublxCmds` stanzas correspond to a configuration that is applied to the host NIC by using `ubxtool` commands.
+For example:
+
+[source,yaml]
+----
+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
+----
+
+The following table describes the equivalent `ubxtool` commands:
+
+.Intel E810 ublxCmds configuration
+[width="90%", options="header"]
+|====
+|ubxtool command|Description
+|`ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1`|Enables antenna voltage control. Enables antenna status to be reported in the `UBX-MON-RF` and `UBX-INF-NOTICE` log messages.
+|`ubxtool -P 29.20 -e GPS`|Enables the antenna to receive GPS signals.
+|`ubxtool -P 29.20 -d Galileo`|Configures the antenna to receive signal from the Galileo GPS satellite.
+|`ubxtool -P 29.20 -d GLONASS`|Disables the antenna from receiving signal from the GLONASS GPS satellite.
+|`ubxtool -P 29.20 -d BeiDou`|Disables the antenna from receiving signal from the BeiDou GPS satellite.
+|`ubxtool -P 29.20 -d SBAS`|Disables the antenna from receiving signal from the SBAS GPS satellite.
+|`ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000`| Configures the GNSS receiver survey-in process to improve its initial position estimate. This can take up to 24 hours to achieve an optimal result.
+|`ubxtool -P 29.20 -p MON-HW`|Runs a single automated scan of the hardware and reports on the NIC state and configuration settings.
+|====
+
+The E810 plugin implements the following interfaces:
+
+.E810 plugin interfaces
+[cols="1,3", width="90%", options="header"]
+|====
+|Interface
+|Description
+
+|`OnPTPConfigChangeE810`
+|Runs whenever you update the `PtpConfig` CR.
+The function parses the plugin options and applies the required configurations to the network device pins based on the configuration data.
+
+|`AfterRunPTPCommandE810`
+|Runs after launching the PTP processes and running the `gpspipe` PTP command.
+The function processes the plugin options and runs `ubxtool` commands, storing the output in the plugin-specific data.
+
+|`PopulateHwConfigE810`
+|Populates the `NodePtpDevice` CR based on hardware-specific data in the `PtpConfig` CR.
+|====
+
+The E810 plugin has the following structs and variables:
+
+.E810 plugin structs and variables
+[cols="1,3", width="90%", options="header"]
+|====
+|Struct
+|Description
+
+|`E810Opts`
+|Represents options for the E810 plugin, including boolean flags and a map of network device pins.
+
+|`E810UblxCmds`
+|Represents configurations for `ubxtool` commands with a boolean flag and a slice of strings for command arguments.
+
+|`E810PluginData`
+|Holds plugin-specific data used during plugin execution.
+|====
--- a/modules/nw-ptp-grandmaster-clock-class-reference.adoc
+++ b/modules/nw-ptp-grandmaster-clock-class-reference.adoc
@@ -0,0 +1,35 @@
+// Module included in the following assemblies:
+//
+// * networking/ptp/configuring-ptp.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="nw-ptp-grandmaster-clock-class-reference_{context}"]
+= Grandmaster clock class sync state reference
+
+The following table describes the PTP grandmaster clock (T-GM) `gm.ClockClass` states.
+Clock class states categorize T-GM clocks based on their accuracy and stability with regard to the Primary Reference Time Clock (PRTC) or other timing source.
+
+Holdover specification is the amount of time a PTP clock can maintain synchronization without receiving updates from the primary time source.
+
+.T-GM clock class states
+[cols="1,3" options="header"]
+|====
+|Clock class state
+|Description
+
+|`gm.ClockClass 6`
+|T-GM clock is connected to a PRTC in `LOCKED` mode.
+For example, the PRTC is traceable to a GNSS time source.
+
+|`gm.ClockClass 7`
+|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.
+|====
+
+For more information, see link:https://www.itu.int/rec/T-REC-G.8275.1-202211-I/en["Phase/time traceability information", ITU-T G.8275.1/Y.1369.1 Recommendations].
--- a/modules/nw-ptp-grandmaster-clock-configuration-reference.adoc
+++ b/modules/nw-ptp-grandmaster-clock-configuration-reference.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: REFERENCE
 [id="nw-ptp-grandmaster-clock-configuration-reference_{context}"]
--- a/modules/nw-ptp-installing-operator-cli.adoc
+++ b/modules/nw-ptp-installing-operator-cli.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/about-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="install-ptp-operator-cli_{context}"]
--- a/modules/nw-ptp-installing-operator-web-console.adoc
+++ b/modules/nw-ptp-installing-operator-web-console.adoc
@@ -1,12 +1,12 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/about-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="install-ptp-operator-web-console_{context}"]
-= Installing the PTP Operator using the web console
+= Installing the PTP Operator by using the web console

-As a cluster administrator, you can install the PTP Operator using the web console.
+As a cluster administrator, you can install the PTP Operator by using the web console.

 [NOTE]
 ====
@@ -40,8 +40,5 @@ If the installation later succeeds with an *InstallSucceeded* message, you can i
 If the Operator does not appear as installed, to troubleshoot further:

 +
-* Go to the *Operators* -> *Installed Operators* page and inspect
-the *Operator Subscriptions* and *Install Plans* tabs for any failure or errors
-under *Status*.
-* Go to the *Workloads* -> *Pods* page and check the logs for pods in the
-`openshift-ptp` project.
+* Go to the *Operators* -> *Installed Operators* page and inspect the *Operator Subscriptions* and *Install Plans* tabs for any failure or errors under *Status*.
+* Go to the *Workloads* -> *Pods* page and check the logs for pods in the `openshift-ptp` project.
--- a/modules/nw-ptp-introduction.adoc
+++ b/modules/nw-ptp-introduction.adoc
@@ -1,29 +1,31 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/about-ptp.adoc

 :_mod-docs-content-type: CONCEPT
-[id="ptp-introduction_{context}"]
-= About PTP
-
-Precision Time Protocol (PTP) is used to synchronize clocks in a network. When used in conjunction with hardware support, PTP is capable of sub-microsecond accuracy, and is more accurate than Network Time Protocol (NTP).
-
 [id="ptp-elements_{context}"]
-== Elements of a PTP domain
+= Elements of a PTP domain
+
+PTP is used to synchronize multiple nodes connected in a network, with clocks for each node.
+The clocks synchronized by PTP are organized in a leader-follower hierarchy.
+The hierarchy is created and updated automatically by the best master clock (BMC) algorithm, which runs on every clock.
+Follower clocks are synchronized to leader clocks, and follower clocks can themselves be the source for other downstream clocks.
+
+.PTP nodes in the network
+image::319_OpenShift_PTP_bare-metal_OCP_nodes_1123_PTP_network.png[Diagram showing a PTP grandmaster clock, boundary clock, and ordinary clock syncing from a GPS satellite that is connected to the PTP grandmaster clock. The boundary and ordinary clocks are synced to the grandmaster clock.]

-PTP is used to synchronize multiple nodes connected in a network, with clocks for each node. The clocks synchronized by PTP are organized in a source-destination hierarchy.
-The hierarchy is created and updated automatically by the best master clock (BMC) algorithm, which runs on every clock. Destination clocks are synchronized to source clocks, and destination clocks can themselves be the source for other downstream clocks.
 The three primary types of PTP clocks are described below.

 Grandmaster clock:: The grandmaster clock provides standard time information to other clocks across the network and ensures accurate and stable synchronisation. It writes time stamps and responds to time requests from other clocks. Grandmaster clocks synchronize to a Global Navigation Satellite System (GNSS) time source. The Grandmaster clock is the authoritative source of time in the network and is responsible for providing time synchronization to all other devices.

-Ordinary clock:: The ordinary clock has a single port connection that can play the role of source or destination clock, depending on its position in the network. The ordinary clock can read and write time stamps.
-
 Boundary clock:: The boundary clock has ports in two or more communication paths and can be a source and a destination to other destination clocks at the same time. The boundary clock works as a destination clock upstream. The destination clock receives the timing message, adjusts for delay, and then creates a new source time signal to pass down the network. The boundary clock produces a new timing packet that is still correctly synced with the source clock and can reduce the number of connected devices reporting directly to the source clock.

+Ordinary clock:: The ordinary clock has a single port connection that can play the role of source or destination clock, depending on its position in the network. The ordinary clock can read and write timestamps.
+
+[discrete]
 [id="ptp-advantages-over-ntp_{context}"]
 == Advantages of PTP over NTP

 One of the main advantages that PTP has over NTP is the hardware support present in various network interface controllers (NIC) and network switches. The specialized hardware allows PTP to account for delays in message transfer and improves the accuracy of time synchronization. To achieve the best possible accuracy, it is recommended that all networking components between PTP clocks are PTP hardware enabled.

-Hardware-based PTP provides optimal accuracy, since the NIC can time stamp the PTP packets at the exact moment they are sent and received. Compare this to software-based PTP, which requires additional processing of the PTP packets by the operating system.
+Hardware-based PTP provides optimal accuracy, since the NIC can timestamp the PTP packets at the exact moment they are sent and received. Compare this to software-based PTP, which requires additional processing of the PTP packets by the operating system.
--- a/modules/nw-ptp-operator-metrics-reference.adoc
+++ b/modules/nw-ptp-operator-metrics-reference.adoc
@@ -0,0 +1,75 @@
+// Module included in the following assemblies:
+//
+// * networking/ptp/using-ptp-events.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="nw-ptp-operator-metrics-reference_{context}"]
+= PTP fast event metrics reference
+
+The following table describes the PTP fast events metrics that are available from cluster nodes where the `linuxptp-daemon` service is running.
+
+[NOTE]
+====
+Some of the following metrics are applicable for PTP grandmaster clocks (T-GM) only.
+====
+
+.PTP fast event metrics
+[cols="1,4,3", options="header"]
+|====
+|Metric
+|Description
+|Example
+
+|`openshift_ptp_clock_class`
+|Returns the PTP clock class for the interface.
+Possible values for PTP clock class are `6` (`LOCKED`), `7` (`HOLDOVER` within specification), `140` (`HOLDOVER` outside specification), and `248` (`FREERUN`).
+Applicable to T-GM clocks only.
+|`openshift_ptp_clock_class {node="compute-1.example.com", process="ptp4l"} 6`
+
+|`openshift_ptp_clock_state`
+|Returns the current PTP clock state for the interface.
+Possible values for PTP clock state are `FREERUN`, `LOCKED`, or `HOLDOVER`.
+|`openshift_ptp_clock_state {iface="CLOCK_REALTIME", node="compute-1.example.com", process="phc2sys"} 1`
+
+|`openshift_ptp_delay_ns`
+|Returns the delay in nanoseconds between the primary clock sending the timing packet and the secondary clock receiving the timing packet.
+|`openshift_ptp_delay_ns {from="master", iface="ens2fx", node="compute-1.example.com", process="ts2phc"} 0`
+
+|`openshift_ptp_frequency_adjustment_ns`
+|Returns the frequency adjustment in nanoseconds between 2 PTP clocks.
+For example, between the upstream clock and the NIC, between the system clock and the NIC, or between the PTP hardware clock (`phc`) and the NIC.
+Applicable to T-GM clocks only.
+|`openshift_ptp_frequency_adjustment_ns {from="phc", iface="CLOCK_REALTIME", node="compute-1.example.com", process="phc2sys"} -6768`
+
+|`openshift_ptp_interface_role`
+|Describes the configured PTP clock role for the interface.
+Possible values are 0 (`PASSIVE`), 1 (`SLAVE`), 2 (`MASTER`), 3 (`FAULTY`), 4 (`UNKNOWN`), or 5 (`LISTENING`).
+
+|`openshift_ptp_interface_role {iface="ens2f0", node="compute-1.example.com", process="ptp4l"} 2`
+
+|`openshift_ptp_max_offset_ns`
+|Returns the maximum offset in nanoseconds between 2 clocks or interfaces.
+For example, between the upstream GNSS clock and the NIC (`ts2phc`), or between the PTP hardware clock (`phc`) and the system clock (`phc2sys`).
+Applicable to T-GM clocks only.
+|`openshift_ptp_max_offset_ns {from="master", iface="ens2fx", node="compute-1.example.com", process="ts2phc"} 1.038099569e+09`
+
+|`openshift_ptp_offset_ns`
+|Returns the offset in nanoseconds between the DPLL clock or the GNSS clock source and the NIC hardware clock.
+Applicable to T-GM clocks only.
+|`openshift_ptp_offset_ns {from="phc", iface="CLOCK_REALTIME", node="compute-1.example.com", process="phc2sys"} -9`
+
+|`openshift_ptp_process_restart_count`
+|Returns a count of the number of times the `ptp4l` process was restarted.
+|`openshift_ptp_process_restart_count {config="ptp4l.0.config", node="compute-1.example.com",process="phc2sys"} 1`
+
+|`openshift_ptp_process_status`
+|Returns a status code that shows whether the PTP process is running or not.
+|`openshift_ptp_process_status {config="ptp4l.0.config", node="compute-1.example.com",process="phc2sys"} 1`
+
+|`openshift_ptp_threshold`
+a|Returns values for `HoldOverTimeout`, `MaxOffsetThreshold`, and `MinOffsetThreshold`.
+
+* `holdOverTimeout` is the time value in seconds before the PTP clock event state changes to `FREERUN` when the PTP master clock is disconnected.
+* `maxOffsetThreshold` and `minOffsetThreshold` are offset values in nanoseconds that compare against the values for `CLOCK_REALTIME` (`phc2sys`) or master offset (`ptp4l`) values that you configure in the `PtpConfig` CR for the NIC.
+|`openshift_ptp_threshold {node="compute-1.example.com", profile="grandmaster", threshold="HoldOverTimeout"} 5`
+|====
--- a/modules/oadp-gcp-wif-cloud-authentication.adoc
+++ b/modules/oadp-gcp-wif-cloud-authentication.adoc
@@ -2,7 +2,7 @@
 //
 // * backup_and_restore/application_backup_and_restore/installing/installing-oadp-gcp.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="oadp-gcp-wif-cloud-authentication_{context}"]
 = Google workload identity federation cloud authentication

@@ -96,5 +96,3 @@ $ oc create namespace <OPERATOR_INSTALL_NS>
 ----
 $ oc apply -f manifests/openshift-adp-cloud-credentials-gcp-credentials.yaml
 ----
-
-
--- a/modules/oadp-installing-dpa-1-2-and-earlier.adoc
+++ b/modules/oadp-installing-dpa-1-2-and-earlier.adoc
@@ -6,7 +6,7 @@
 // * backup_and_restore/application_backup_and_restore/installing/installing-oadp-mcg.adoc
 // * backup_and_restore/application_backup_and_restore/installing/installing-oadp-ocs.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="oadp-installing-dpa-1-2-and-earlier_{context}"]
 = Installing the Data Protection Application 1.2 and earlier

@@ -403,4 +403,4 @@ NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
 dpa-sample-1   Available   1s               3d16h   true
 ----

-. Verify that the `PHASE` is in `Available`.
+. Verify that the `PHASE` is in `Available`.
--- a/modules/oadp-installing-dpa-1-3.adoc
+++ b/modules/oadp-installing-dpa-1-3.adoc
@@ -6,7 +6,7 @@
 // * backup_and_restore/application_backup_and_restore/installing/installing-oadp-mcg.adoc
 // * backup_and_restore/application_backup_and_restore/installing/installing-oadp-ocs.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="oadp-installing-dpa-1-3_{context}"]
 = Installing the Data Protection Application 1.3

@@ -419,4 +419,4 @@ NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
 dpa-sample-1   Available   1s               3d16h   true
 ----

-. Verify that the `PHASE` is in `Available`.
+. Verify that the `PHASE` is in `Available`.
--- a/modules/ptp-cloud-event-proxy-sidecar-api.adoc
+++ b/modules/ptp-cloud-event-proxy-sidecar-api.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/ptp-cloud-events-consumer-dev-reference.adoc
+// * networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc

 :_mod-docs-content-type: REFERENCE
 [id="ptp-cloud-event-proxy-sidecar-api_{context}"]
--- a/modules/ptp-configuring-linuxptp-services-as-boundary-clock-dual-nic.adoc
+++ b/modules/ptp-configuring-linuxptp-services-as-boundary-clock-dual-nic.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/configuring-ptp.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="ptp-configuring-linuxptp-services-as-bc-for-dual-nic_{context}"]
--- a/modules/ptp-dual-nics.adoc
+++ b/modules/ptp-dual-nics.adoc
@@ -1,8 +1,8 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/about-ptp.adoc

-:_module-type: CONCEPT
+:_mod-docs-content-type: CONCEPT
 [id="ptp-dual-nics_{context}"]
 = Using PTP with dual NIC hardware

--- a/modules/ptp-events-consumer-application.adoc
+++ b/modules/ptp-events-consumer-application.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/ptp-cloud-events-consumer-dev-reference.adoc
+// * networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc

 :_mod-docs-content-type: REFERENCE
 [id="ptp-events-consumer-application_{context}"]
--- a/modules/ptp-getting-the-current-ptp-clock-status.adoc
+++ b/modules/ptp-getting-the-current-ptp-clock-status.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/ptp-cloud-events-consumer-dev-reference.adoc
+// * networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc

 :_mod-docs-content-type: REFERENCE
 [id="ptp-getting-the-current-ptp-clock-status_{context}"]
--- a/modules/ptp-linuxptp-introduction.adoc
+++ b/modules/ptp-linuxptp-introduction.adoc
@@ -1,12 +1,15 @@
 // Module included in the following assemblies:
 //
-// * networking/using-ptp.adoc
+// * networking/ptp/about-ptp.adoc

 :_mod-docs-content-type: CONCEPT
 [id="ptp-linuxptp-introduction_{context}"]
-= Overview of linuxptp in {product-title} nodes
+= Overview of linuxptp and gpsd in {product-title} nodes
+
+{product-title} uses the PTP Operator with `linuxptp` and `gpsd` packages for high precision network synchronization.
+The `linuxptp` package provides tools and daemons for PTP timing in networks.
+Cluster hosts with Global Navigation Satellite System (GNSS) capable NICs use `gpsd` to interface with GNSS clock sources.

-{product-title} uses PTP and `linuxptp` for high precision system timing in bare-metal infrastructure.
 The `linuxptp` package includes the `ts2phc`, `pmc`, `ptp4l`, and `phc2sys` programs for system clock synchronization.

 ts2phc:: `ts2phc` synchronizes the PTP hardware clock (PHC) across PTP devices with a high degree of precision.
@@ -24,10 +27,17 @@ pmc:: `pmc` implements a PTP management client (`pmc`) according to IEEE standar

 ptp4l:: `ptp4l` implements the PTP boundary clock and ordinary clock and runs as a system daemon.
 `ptp4l` does the following:
-
 * Synchronizes the PHC to the source clock with hardware time stamping
 * Synchronizes the system clock to the source clock with software time stamping

 phc2sys:: `phc2sys` synchronizes the system clock to the PHC on the network interface controller (NIC).
 The `phc2sys` system daemon continuously monitors the PHC for timing information.
 When it detects a timing error, the PHC corrects the system clock.
+
+The `gpsd` package includes the `ubxtool`, `gspipe`, `gpsd`, programs for GNSS clock synchronization with the host clock.
+
+ubxtool:: `ubxtool` CLI allows you to communicate with a u-blox GPS system. The `ubxtool` CLI uses the u-blox binary protocol to communicate with the GPS.
+
+gpspipe:: `gpspipe` connects to `gpsd` output and pipes it to `stdout`.
+
+gpsd:: `gpsd` is a service daemon that monitors one or more GPS or AIS receivers connected to the host.
--- a/modules/ptp-overview-of-gnss-grandmaster-clock.adoc
+++ b/modules/ptp-overview-of-gnss-grandmaster-clock.adoc
@@ -0,0 +1,30 @@
+// Module included in the following assemblies:
+//
+// * networking/ptp/about-ptp.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="ptp-overview-of-gnss-grandmaster-clock_{context}"]
+= Overview of GNSS timing for PTP grandmaster clocks
+
+{product-title} supports receiving precision PTP timing from Global Navigation Satellite System (GNSS) sources and grandmaster clocks (T-GM) in the cluster.
+
+[IMPORTANT]
+====
+{product-title} supports PTP timing from GNSS sources with Intel E810 Westport Channel NICs only.
+====
+
+.Overview of Synchronization with GNSS and T-GM
+image::319_OpenShift_PTP_bare-metal_OCP_nodes_1023_PTP.png[GNSS and T-GM system architecture]
+
+Global Navigation Satellite System (GNSS)::
+GNSS is a satellite-based system used to provide positioning, navigation, and timing information to receivers around the globe.
+In PTP, GNSS receivers are often used as a highly accurate and stable reference clock source.
+These receivers receive signals from multiple GNSS satellites, allowing them to calculate precise time information.
+The timing information obtained from GNSS is used as a reference by the PTP grandmaster clock.
+
+By using GNSS as a reference, the grandmaster clock in the PTP network can provide highly accurate timestamps to other devices, enabling precise synchronization across the entire network.
+
+Digital Phase-Locked Loop (DPLL)::
+DPLL provides clock synchronization between different PTP nodes in the network.
+DPLL compares the phase of the local system clock signal with the phase of the incoming synchronization signal, for example, PTP messages from the PTP grandmaster clock.
+The DPLL continuously adjusts the local clock frequency and phase to minimize the phase difference between the local clock and the reference clock.
--- a/modules/ptp-reference-deployment-and-service-crs.adoc
+++ b/modules/ptp-reference-deployment-and-service-crs.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/ptp-cloud-events-consumer-dev-reference.adoc
+// * networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc

 :_mod-docs-content-type: REFERENCE
 [id="ptp-reference-deployment-and-service-crs_{context}"]
--- a/modules/ptp-subscribing-consumer-app-to-events.adoc
+++ b/modules/ptp-subscribing-consumer-app-to-events.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/ptp-cloud-events-consumer-dev-reference.adoc
+// * networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc

 :_mod-docs-content-type: REFERENCE
 [id="ptp-subscribing-consumer-app-to-events_{context}"]
--- a/modules/ptp-using-hardware-specific-nic-features.adoc
+++ b/modules/ptp-using-hardware-specific-nic-features.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// * networking/ptp/configuring-ptp.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="ptp-using-hardware-specific-nic-features_{context}"]
+= Using hardware-specific NIC features with the PTP Operator
+
+NIC hardware with built-in PTP capabilities sometimes require device-specific configuration.
+You can use hardware-specific NIC features for supported hardware with the PTP Operator by configuring a plugin in the `PtpConfig` custom resource (CR).
+The `linuxptp-daemon` service uses the named parameters in the `plugin` stanza to start `linuxptp` processes (`ptp4l` and `phc2sys`) based on the specific hardware configuration.
+
+[IMPORTANT]
+====
+In {product-title} {product-version}, the Intel E810 NIC is supported with a `PtpConfig` plugin.
+====
--- a/modules/ptp-verifying-events-consumer-app-is-receiving-events.adoc
+++ b/modules/ptp-verifying-events-consumer-app-is-receiving-events.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * networking/ptp-cloud-events-consumer-dev-reference.adoc
+// * networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc

 :_mod-docs-content-type: PROCEDURE
 [id="ptp-verifying-events-consumer-app-is-receiving-events_{context}"]
--- a/modules/troubleshooting-network-observability-loki-resource-exhausted.adoc
+++ b/modules/troubleshooting-network-observability-loki-resource-exhausted.adoc
@@ -2,15 +2,15 @@

 // * networking/network_observability/troubleshooting-network-observability.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="network-observability-troubleshooting-loki-resource-exhausted_{context}"]
 = Troubleshooting Loki ResourceExhausted error
-Loki may return a `ResourceExhausted` error when network flow data sent by Network Observability exceeds the configured maximum message size. If you are using the Loki Operator, this maximum message size is configured to 100 MiB. 
+Loki may return a `ResourceExhausted` error when network flow data sent by Network Observability exceeds the configured maximum message size. If you are using the Loki Operator, this maximum message size is configured to 100 MiB.

 .Procedure
 . Navigate to *Operators* -> *Installed Operators*, viewing *All projects* from the *Project* drop-down menu.
 . In the *Provided APIs* list, select the Network Observability Operator.
-. Click the *Flow Collector* then the *YAML view* tab. 
+. Click the *Flow Collector* then the *YAML view* tab.
 .. If you are using the Loki Operator, check that the `spec.loki.batchSize` value does not exceed 98 MiB.
-.. If you are using a Loki installation method that is different from the Red Hat Loki Operator, such as Grafana Loki, verify that the `grpc_server_max_recv_msg_size` link:https://grafana.com/docs/loki/latest/configure/#server[Grafana Loki server setting] is higher than the `FlowCollector` resource `spec.loki.batchSize` value. If it is not, you must either increase the `grpc_server_max_recv_msg_size` value, or decrease the `spec.loki.batchSize` value so that it is lower than the limit. 
-. Click *Save* if you edited the *FlowCollector*.
+.. If you are using a Loki installation method that is different from the Red Hat Loki Operator, such as Grafana Loki, verify that the `grpc_server_max_recv_msg_size` link:https://grafana.com/docs/loki/latest/configure/#server[Grafana Loki server setting] is higher than the `FlowCollector` resource `spec.loki.batchSize` value. If it is not, you must either increase the `grpc_server_max_recv_msg_size` value, or decrease the `spec.loki.batchSize` value so that it is lower than the limit.
+. Click *Save* if you edited the *FlowCollector*.
--- a/modules/virt-attaching-virtio-disk-to-windows.adoc
+++ b/modules/virt-attaching-virtio-disk-to-windows.adoc
@@ -2,7 +2,7 @@
 //
 // * virt/virtual_machines/creating_vms/virt-installing-qemu-guest-agent.adoc

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="virt-attaching-virtio-disk-to-windows_{context}"]
 = Attaching VirtIO container disk to Windows VMs during installation

@@ -15,4 +15,4 @@ You must attach the VirtIO container disk to the Windows VM to install the neces
 . Click the *Customize VirtualMachine parameters*.
 . Click *Create VirtualMachine*.

-After the VM is created, the `virtio-win` SATA CD disk will be attached to the VM.
+After the VM is created, the `virtio-win` SATA CD disk will be attached to the VM.
--- a/modules/virt-enabling-volume-snapshot-boot-source.adoc
+++ b/modules/virt-enabling-volume-snapshot-boot-source.adoc
@@ -3,7 +3,7 @@
 // * virt/storage/virt-automatic-bootsource-updates.adoc
 //

-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="virt-enabling-volume-snapshot-boot-source_{context}"]
 = Enabling volume snapshot boot sources

@@ -54,4 +54,4 @@ $ oc get storageprofile <storage_class>  -oyaml

 . Confirm that the `dataImportCronSourceFormat` specification of the `StorageProfile` is set to 'snapshot', and that any `DataSource` objects that the `DataImportCron` points to now reference volume snapshots.

-You can now use these boot sources to create virtual machines.
+You can now use these boot sources to create virtual machines.
--- a/networking/ptp/_attributes
+++ b/networking/ptp/_attributes
@@ -0,0 +1 @@
+../../_attributes/
--- a/networking/ptp/about-ptp.adoc
+++ b/networking/ptp/about-ptp.adoc
@@ -0,0 +1,38 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="about-ptp"]
+= About PTP in {product-title} cluster nodes
+include::_attributes/common-attributes.adoc[]
+:context: about-ptp
+
+toc::[]
+
+Precision Time Protocol (PTP) is used to synchronize clocks in a network.
+When used in conjunction with hardware support, PTP is capable of sub-microsecond accuracy, and is more accurate than Network Time Protocol (NTP).
+
+You can configure `linuxptp` services and use PTP-capable hardware in {product-title} cluster nodes.
+
+Use the {product-title} web console or OpenShift CLI (`oc`) to install PTP by deploying the PTP Operator. The PTP Operator creates and manages the `linuxptp` services and provides the following features:
+
+* Discovery of the PTP-capable devices in the cluster.
+
+* Management of the configuration of `linuxptp` services.
+
+* Notification of PTP clock events that negatively affect the performance and reliability of your application with the PTP Operator `cloud-event-proxy` sidecar.
+
+[NOTE]
+====
+The PTP Operator works with PTP-capable devices on clusters provisioned only on bare-metal infrastructure.
+====
+
+include::modules/nw-ptp-introduction.adoc[leveloffset=+1]
+
+[IMPORTANT]
+====
+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:../../post_installation_configuration/machine-configuration-tasks.adoc#cnf-disable-chronyd_post-install-machine-configuration-tasks[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]
--- a/networking/ptp/configuring-ptp.adoc
+++ b/networking/ptp/configuring-ptp.adoc
@@ -0,0 +1,67 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="configuring-ptp"]
+= Configuring PTP devices
+include::_attributes/common-attributes.adoc[]
+:context: configuring-ptp
+
+toc::[]
+
+The PTP Operator adds the `NodePtpDevice.ptp.openshift.io` custom resource definition (CRD) to {product-title}.
+
+When installed, the PTP Operator searches your cluster for PTP-capable network devices on each node. It creates and updates a `NodePtpDevice` custom resource (CR) object for each node that provides a compatible PTP-capable network device.
+
+include::modules/nw-ptp-installing-operator-cli.adoc[leveloffset=+1]
+
+include::modules/nw-ptp-installing-operator-web-console.adoc[leveloffset=+1]
+
+include::modules/nw-ptp-device-discovery.adoc[leveloffset=+1]
+
+include::modules/ptp-using-hardware-specific-nic-features.adoc[leveloffset=+1]
+
+include::modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../networking/ptp/using-ptp-events.adoc#cnf-configuring-the-ptp-fast-event-publisher_using-ptp-hardware-fast-events-framework[Configuring the PTP fast event notifications publisher]
+
+include::modules/nw-ptp-grandmaster-clock-configuration-reference.adoc[leveloffset=+2]
+
+include::modules/nw-ptp-grandmaster-clock-class-reference.adoc[leveloffset=+2]
+
+include::modules/nw-ptp-e810-hardware-configuration-reference.adoc[leveloffset=+2]
+
+include::modules/nw-ptp-configuring-linuxptp-services-as-boundary-clock.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../networking/ptp/configuring-ptp.adoc#cnf-configuring-fifo-priority-scheduling-for-ptp_configuring-ptp[Configuring FIFO priority scheduling for PTP hardware]
+
+* xref:../../networking/ptp/using-ptp-events.adoc#cnf-configuring-the-ptp-fast-event-publisher_using-ptp-hardware-fast-events-framework[Configuring the PTP fast event notifications publisher]
+
+include::modules/ptp-configuring-linuxptp-services-as-boundary-clock-dual-nic.adoc[leveloffset=+2]
+
+include::modules/nw-ptp-configuring-linuxptp-services-as-ordinary-clock.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../networking/ptp/configuring-ptp.adoc#cnf-configuring-fifo-priority-scheduling-for-ptp_configuring-ptp[Configuring FIFO priority scheduling for PTP hardware]
+
+* xref:../../networking/ptp/using-ptp-events.adoc#cnf-configuring-the-ptp-fast-event-publisher_using-ptp-hardware-fast-events-framework[Configuring the PTP fast event notifications publisher]
+
+include::modules/nw-columbiaville-ptp-config-refererence.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+.Additional resources
+
+* For a complete example CR that configures `linuxptp` services as an ordinary clock with PTP fast events, see xref:../../networking/ptp/configuring-ptp.adoc#configuring-linuxptp-services-as-ordinary-clock_configuring-ptp[Configuring linuxptp services as ordinary clock].
+
+include::modules/cnf-configuring-fifo-priority-scheduling-for-ptp.adoc[leveloffset=+1]
+
+include::modules/cnf-configuring-log-filtering-for-linuxptp.adoc[leveloffset=+1]
+
+include::modules/cnf-troubleshooting-common-ptp-operator-issues.adoc[leveloffset=+1]
+
+include::modules/cnf-about-collecting-ptp-data.adoc[leveloffset=+1]
--- a/networking/ptp/images
+++ b/networking/ptp/images
@@ -0,0 +1 @@
+../../images/
--- a/networking/ptp/modules
+++ b/networking/ptp/modules
@@ -0,0 +1 @@
+../../modules/
--- a/networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc
+++ b/networking/ptp/ptp-cloud-events-consumer-dev-reference.adoc
@@ -10,7 +10,7 @@ When developing consumer applications that make use of Precision Time Protocol (
 The `cloud-event-proxy` container receives the events from the PTP Operator pod and passes it to the consumer application.
 The consumer application subscribes to the events posted in the `cloud-event-proxy` container by using a REST API.

-For more information about deploying PTP events applications, see xref:../networking/using-ptp.adoc#cnf-about-ptp-fast-event-notifications-framework_using-ptp[About the PTP fast event notifications framework].
+For more information about deploying PTP events applications, see xref:../../networking/ptp/using-ptp-events.adoc#cnf-about-ptp-fast-event-notifications-framework_using-ptp-hardware-fast-events-framework[About the PTP fast event notifications framework].

 [NOTE]
 ====
--- a/networking/ptp/snippets
+++ b/networking/ptp/snippets
@@ -0,0 +1 @@
+../../snippets/
--- a/networking/ptp/using-ptp-events.adoc
+++ b/networking/ptp/using-ptp-events.adoc
@@ -0,0 +1,66 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="using-ptp-hardware-fast-events-framework"]
+= Using the PTP hardware fast event notifications framework
+include::_attributes/common-attributes.adoc[]
+:context: using-ptp-hardware-fast-events-framework
+
+toc::[]
+
+Cloud native applications such as virtual RAN (vRAN) require access to notifications about hardware timing events that are critical to the functioning of the overall network.
+PTP clock synchronization errors can negatively affect the performance and reliability of your low-latency application, for example, a vRAN application running in a distributed unit (DU).
+
+include::modules/cnf-about-ptp-and-clock-synchronization.adoc[leveloffset=+1]
+
+include::modules/cnf-about-ptp-fast-event-notifications-framework.adoc[leveloffset=+1]
+
+include::modules/cnf-configuring-the-ptp-fast-event-publisher.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* For a complete example CR that configures `linuxptp` services as an ordinary clock with PTP fast events, see xref:../../networking/ptp/configuring-ptp.adoc#configuring-linuxptp-services-as-ordinary-clock_configuring-ptp[Configuring linuxptp services as ordinary clock].
+
+include::modules/cnf-migrating-from-amqp-to-http-transport.adoc[leveloffset=+1]
+
+include::modules/cnf-installing-amq-interconnect-messaging-bus.adoc[leveloffset=+1]
+
+[id="subscribing-du-applications-to-ptp-events-rest-api-reference_{context}"]
+== Subscribing DU applications to PTP events with the REST API
+
+Subscribe applications to PTP events by using the resource address `/cluster/node/<node_name>/ptp`, where `<node_name>` is the cluster node running the DU application.
+
+Deploy your `cloud-event-consumer` DU application container and `cloud-event-proxy` sidecar container in a separate DU application pod. The `cloud-event-consumer` DU application subscribes to the `cloud-event-proxy` container in the application pod.
+
+Use the following API endpoints to subscribe the `cloud-event-consumer` DU application to PTP events posted by the `cloud-event-proxy` container at [x-]`http://localhost:8089/api/ocloudNotifications/v1/` in the DU application pod:
+
+* xref:../../networking/ptp/using-ptp-events.adoc#api-ocloud-notifications-v1-subscriptions_{context}[`/api/ocloudNotifications/v1/subscriptions`]
+- `POST`: Creates a new subscription
+- `GET`: Retrieves a list of subscriptions
+
+* xref:../../networking/ptp/using-ptp-events.adoc#api-ocloud-notifications-v1-subscriptions-subscription_id_{context}[`/api/ocloudNotifications/v1/subscriptions/<subscription_id>`]
+- `GET`: Returns details for the specified subscription ID
+
+* xref:../../networking/ptp/using-ptp-events.adoc#api-ocloudnotifications-v1-health_{context}[`/api/ocloudNotifications/v1/health`]
+- `GET`: Returns the health status of `ocloudNotifications` API
+
+* xref:../../networking/ptp/using-ptp-events.adoc#api-ocloudnotifications-v1-publishers_{context}[`api/ocloudNotifications/v1/publishers`]
+- `GET`: Returns an array of `os-clock-sync-state`, `ptp-clock-class-change`, `lock-state`, and `gnss-sync-status` messages for the cluster node
+
+* xref:../../networking/ptp/using-ptp-events.adoc#resource-address-current-state_{context}[`/api/ocloudnotifications/v1/<resource_address>/CurrentState`]
+- `GET`: Returns the current state of one the following event types: `os-clock-sync-state`, `ptp-clock-class-change`, `lock-state`, or `gnss-state-change` events
+
+[NOTE]
+====
+`9089` is the default port for the `cloud-event-consumer` container deployed in the application pod. You can configure a different port for your DU application as required.
+====
+
+include::modules/cnf-fast-event-notifications-api-refererence.adoc[leveloffset=+2]
+
+include::modules/cnf-monitoring-fast-events-metrics.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../monitoring/managing-metrics.adoc#managing-metrics[Managing metrics]
+
+include::modules/nw-ptp-operator-metrics-reference.adoc[leveloffset=+1]
--- a/networking/using-ptp.adoc
+++ b/networking/using-ptp.adoc
@@ -1,121 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="using-ptp"]
-= Using PTP hardware
-include::_attributes/common-attributes.adoc[]
-:context: using-ptp
-
-toc::[]
-
-You can configure `linuxptp` services and use PTP-capable hardware in {product-title} cluster nodes.
-
-[id="about-using-ptp-hardware"]
-== About PTP hardware
-
-You can use the {product-title} console or OpenShift CLI (`oc`) to install PTP by deploying the PTP Operator. The PTP Operator creates and manages the `linuxptp` services and provides the following features:
-
-* Discovery of the PTP-capable devices in the cluster.
-
-* Management of the configuration of `linuxptp` services.
-
-* Notification of PTP clock events that negatively affect the performance and reliability of your application with the PTP Operator `cloud-event-proxy` sidecar.
-
-[NOTE]
-====
-The PTP Operator works with PTP-capable devices on clusters provisioned only on bare-metal infrastructure.
-====
-
-include::modules/nw-ptp-introduction.adoc[leveloffset=+1]
-
-[IMPORTANT]
-====
-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:../post_installation_configuration/machine-configuration-tasks.adoc#cnf-disable-chronyd_post-install-machine-configuration-tasks[Disabling chrony time service].
-====
-
-include::modules/ptp-dual-nics.adoc[leveloffset=+2]
-
-include::modules/ptp-linuxptp-introduction.adoc[leveloffset=+1]
-
-include::modules/nw-ptp-installing-operator-cli.adoc[leveloffset=+1]
-
-include::modules/nw-ptp-installing-operator-web-console.adoc[leveloffset=+1]
-
-== Configuring PTP devices
-
-The PTP Operator adds the `NodePtpDevice.ptp.openshift.io` custom resource definition (CRD) to {product-title}.
-
-When installed, the PTP Operator searches your cluster for PTP-capable network devices on each node. It creates and updates a `NodePtpDevice` custom resource (CR) object for each node that provides a compatible PTP-capable network device.
-
-include::modules/nw-ptp-device-discovery.adoc[leveloffset=+2]
-
-include::modules/nw-ptp-configuring-linuxptp-services-as-grandmaster-clock.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../networking/using-ptp.adoc#cnf-configuring-the-ptp-fast-event-publisher_using-ptp[Configuring the PTP fast event notifications publisher]
-
-include::modules/nw-ptp-grandmaster-clock-configuration-reference.adoc[leveloffset=+3]
-
-include::modules/nw-ptp-configuring-linuxptp-services-as-ordinary-clock.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* For more information about FIFO priority scheduling on PTP hardware, see xref:../networking/using-ptp.adoc#cnf-configuring-fifo-priority-scheduling-for-ptp_using-ptp[Configuring FIFO priority scheduling for PTP hardware].
-
-* For more information about configuring PTP fast events, see xref:../networking/using-ptp.adoc#cnf-configuring-the-ptp-fast-event-publisher_using-ptp[Configuring the PTP fast event notifications publisher].
-
-include::modules/nw-ptp-configuring-linuxptp-services-as-boundary-clock.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* For more information about FIFO priority scheduling on PTP hardware, see xref:../networking/using-ptp.adoc#cnf-configuring-fifo-priority-scheduling-for-ptp_using-ptp[Configuring FIFO priority scheduling for PTP hardware].
-
-* For more information about configuring PTP fast events, see xref:../networking/using-ptp.adoc#cnf-configuring-the-ptp-fast-event-publisher_using-ptp[Configuring the PTP fast event notifications publisher].
-
-include::modules/ptp-configuring-linuxptp-services-as-boundary-clock-dual-nic.adoc[leveloffset=+2]
-
-include::modules/nw-columbiaville-ptp-config-refererence.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* For a complete example CR that configures `linuxptp` services as an ordinary clock with PTP fast events, see xref:../networking/using-ptp.adoc#configuring-linuxptp-services-as-ordinary-clock_using-ptp[Configuring linuxptp services as ordinary clock].
-
-include::modules/cnf-configuring-fifo-priority-scheduling-for-ptp.adoc[leveloffset=+2]
-
-include::modules/cnf-configuring-log-filtering-for-linuxptp.adoc[leveloffset=+2]
-
-include::modules/cnf-troubleshooting-common-ptp-operator-issues.adoc[leveloffset=+1]
-
-include::modules/cnf-about-collecting-ptp-data.adoc[leveloffset=+2]
-
-== PTP hardware fast event notifications framework
-
-Cloud native applications such as virtual RAN (vRAN) require access to notifications about hardware timing events that are critical to the functioning of the overall network.
-PTP clock synchronization errors can negatively affect the performance and reliability of your low-latency application, for example, a vRAN application running in a distributed unit (DU).
-
-include::modules/cnf-about-ptp-and-clock-synchronization.adoc[leveloffset=+2]
-
-include::modules/cnf-about-ptp-fast-event-notifications-framework.adoc[leveloffset=+2]
-
-include::modules/cnf-configuring-the-ptp-fast-event-publisher.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* For a complete example CR that configures `linuxptp` services as an ordinary clock with PTP fast events, see xref:../networking/using-ptp.adoc#configuring-linuxptp-services-as-ordinary-clock_using-ptp[Configuring linuxptp services as ordinary clock].
-
-include::modules/cnf-migrating-from-amqp-to-http-transport.adoc[leveloffset=+2]
-
-include::modules/cnf-installing-amq-interconnect-messaging-bus.adoc[leveloffset=+2]
-
-include::modules/cnf-fast-event-notifications-api-refererence.adoc[leveloffset=+2]
-
-include::modules/cnf-monitoring-fast-events-metrics.adoc[leveloffset=+2]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../monitoring/managing-metrics.adoc#managing-metrics[Managing metrics]
--- a/scalability_and_performance/ztp_far_edge/ztp-advanced-policy-config.adoc
+++ b/scalability_and_performance/ztp_far_edge/ztp-advanced-policy-config.adoc
@@ -75,7 +75,7 @@ include::modules/ztp-configuring-ptp-fast-events-amqp.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources

-* xref:../../networking/using-ptp.adoc#cnf-installing-amq-interconnect-messaging-bus_using-ptp[Installing the AMQ messaging bus]
+* xref:../../networking/ptp/using-ptp-events.adoc#cnf-installing-amq-interconnect-messaging-bus_using-ptp-events[Installing the AMQ messaging bus]
 * For more information about container image registries, see xref:../../registry/index.adoc#registry-overview[{product-registry} overview].

 [id="ztp-advanced-policy-config-bare-metal_{context}"]
--- a/snippets/ptp-clock-holdover-note.adoc
+++ b/snippets/ptp-clock-holdover-note.adoc
@@ -0,0 +1,10 @@
+:_mod-docs-content-type: SNIPPET
+[NOTE]
+====
+During holdover, the T-GM or T-BC uses the internal system clock to continue generating time synchronization signals as accurately as possible based on the last known good reference.
+
+You can set the time holdover specification threshold controlling the time spent advertising `ClockClass` values `7` or `135` to `0` so that the T-GM or T-BC advertises a degraded `ClockClass` value directly after losing traceability to a PRTC.
+In this case, after initially advertising `ClockClass` values between `140–165`, a clock can still be within the holdover specification.
+====
+
+For more information, see link:https://www.itu.int/rec/T-REC-G.8275.1-202211-I/en["Phase/time traceability information", ITU-T G.8275.1/Y.1369.1 Recommendations].
--- a/snippets/ptp_PtpConfigGmWpc.yaml
+++ b/snippets/ptp_PtpConfigGmWpc.yaml
@@ -3,8 +3,6 @@ kind: PtpConfig
 metadata:
  name: grandmaster
  namespace: openshift-ptp
-  annotations:
-    ran.openshift.io/ztp-deploy-wave: "10"
 spec:
  profile:
  - name: "grandmaster"
@@ -16,7 +14,71 @@ spec:
      logReduce: "true"
    plugins:
      e810:
-        enableDefaultConfig: true
+        enableDefaultConfig: false
+        settings:
+          LocalMaxHoldoverOffSet: 1500
+          LocalHoldoverTimeout: 14400
+          MaxInSpecOffset: 100
+        pins: $e810_pins
+        #  "$iface_master":
+        #    "U.FL2": "0 2"
+        #    "U.FL1": "0 1"
+        #    "SMA2": "0 2"
+        #    "SMA1": "0 1"
+        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
    ts2phcOpts: " "
    ts2phcConf: |
      [nmea]
--- a/snippets/snip-noobaa-and-mcg.adoc
+++ b/snippets/snip-noobaa-and-mcg.adoc
@@ -1,8 +1,8 @@
-:_content-type: SNIPPET
+:_mod-docs-content-type: SNIPPET

 [NOTE]
 ====
 Unless specified otherwise, "NooBaa" refers to the open source project that provides lightweight object storage, while "Multicloud Object Gateway (MCG)" refers to the Red Hat distribution of NooBaa.

 For more information on the MCG, see link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.13/html-single/managing_hybrid_and_multicloud_resources/index#accessing-the-multicloud-object-gateway-with-your-applications_rhodf[Accessing the Multicloud Object Gateway with your applications].
-====
+====
--- a/snippets/snip-post-mig-hook
+++ b/snippets/snip-post-mig-hook
@@ -1,4 +1,4 @@
-:_content-type: SNIPPET
+:_mod-docs-content-type: SNIPPET

 [NOTE]
 ====
@@ -7,4 +7,4 @@ Post-migration hooks are not likely to work well with the OADP 1.3 Data Mover.
 The OADP 1.1 and OADP 1.2 Data Movers use synchronous processes to back up and restore application data. Because the processes are synchronous, users can be sure that any post-restore hooks start only after the persistent volumes (PVs) of the related pods are released by the persistent volume claim (PVC) of the Data Mover.

 However, the OADP 1.3 Data Mover uses an asynchronous process. As a result of this difference in sequencing, a post-restore hook might be called before the related PVs were released by the PVC of the Data Mover. If this happens, the pod remains in `Pending` status and cannot run the hook. The hook attempt might time out before the pod is released, leading to a `PartiallyFailed` restore operation.
-====
+====