mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
TELCODOCS-323: Updates for TELCODOCS-323 OCP 4.10 PTP.
This commit is contained in:
Aidan Reilly
BIN
images/218_OpenShift_PTP_events_0222.png
Normal file
BIN
images/218_OpenShift_PTP_events_0222.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
@@ -16,5 +16,5 @@ Fast event notifications are generated by the PTP Operator in {product-title} fo
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
PTP fast event notifications are available only for network interfaces configured to use PTP ordinary clocks.
|
||||
PTP fast event notifications are available for network interfaces configured to use PTP ordinary clocks or PTP boundary clocks.
|
||||
====
|
||||
|
||||
@@ -6,7 +6,10 @@
|
||||
[id="cnf-about-ptp-fast-event-notifications-framework_{context}"]
|
||||
= About the PTP fast event notifications framework
|
||||
|
||||
You can subscribe Distributed unit (DU) applications to Precision Time Protocol (PTP) fast events notifications that are generated by {product-title} with the PTP Operator and `cloud-event-proxy` sidecar container. You enable the `cloud-event-proxy` sidecar container by setting the `enableEventPublisher` field to `true` in the `ptpOperatorConfig` custom resource (CR) and specifying a `transportHost` address. PTP fast events use an Advanced Message Queuing Protocol (AMQP) event notification bus provided by the AMQ Interconnect Operator. AMQ Interconnect is a component of Red Hat AMQ, a messaging router that provides flexible routing of messages between any AMQP-enabled endpoints.
|
||||
You can subscribe distributed unit (DU) applications to Precision Time Protocol (PTP) fast events notifications that are generated by {product-title} with the PTP Operator and `cloud-event-proxy` sidecar container. You enable the `cloud-event-proxy` sidecar container by setting the `enableEventPublisher` field to `true` in the `ptpOperatorConfig` custom resource (CR) and specifying an Advanced Message Queuing Protocol (AMQP) `transportHost` address. PTP fast events use an AMQP event notification bus provided by the AMQ Interconnect Operator. AMQ Interconnect is a component of Red Hat AMQ, a messaging router that provides flexible routing of messages between any AMQP-enabled endpoints. An overview of the PTP fast events framework is below:
|
||||
|
||||
.Overview of PTP fast events
|
||||
image::218_OpenShift_PTP_events_0222.png[Overview of PTP fast events]
|
||||
|
||||
The `cloud-event-proxy` sidecar container can access the same resources as the primary vRAN application without using any of the resources of the primary application and with no significant latency.
|
||||
|
||||
|
||||
206
modules/cnf-configuring-cvl-nic-as-oc.adoc
Normal file
206
modules/cnf-configuring-cvl-nic-as-oc.adoc
Normal file
@@ -0,0 +1,206 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/using-ptp.adoc
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="cnf-configuring-cvl-nic-as-ptp-slave_{context}"]
|
||||
= Configuring linuxptp services as an ordinary clock for Intel Columbiaville NIC
|
||||
|
||||
You can configure `linuxptp` services as a single ordinary clock for nodes with an Intel 800-Series Columbiaville NIC installed.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The following `PtpConfig` CR also configures PTP fast events by setting values for `ptp4lOpts`, `ptp4lConf` and `ptpClockThreshold`.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* Install one or more Intel 800-Series Columbiaville NICs in your cluster bare-metal hosts.
|
||||
* Install the OpenShift CLI (`oc`).
|
||||
* Log in as a user with `cluster-admin` privileges.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Create the `PtpConfig` CR for nodes with matching role.
|
||||
|
||||
.. Save the following YAML in the `cvl-ptp-ordinary-clock.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: ptp.openshift.io/v1
|
||||
kind: PtpConfig
|
||||
metadata:
|
||||
name: slave
|
||||
namespace: openshift-ptp
|
||||
spec:
|
||||
profile:
|
||||
- name: "slave"
|
||||
interface: <interface_name> <1>
|
||||
ptp4lOpts: "-2 --summary_interval -4" <2>
|
||||
phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
|
||||
ptpSchedulingPolicy: "SCHED_FIFO" <3>
|
||||
ptpSchedulingPriority: 65 <4>
|
||||
ptp4lConf: |
|
||||
[global]
|
||||
#
|
||||
# Default Data Set
|
||||
#
|
||||
twoStepFlag 1
|
||||
slaveOnly 0
|
||||
priority1 128
|
||||
priority2 128
|
||||
domainNumber 24
|
||||
#utc_offset 37
|
||||
clockClass 248
|
||||
clockAccuracy 0xFE
|
||||
offsetScaledLogVariance 0xFFFF
|
||||
free_running 0
|
||||
freq_est_interval 1
|
||||
dscp_event 0
|
||||
dscp_general 0
|
||||
dataset_comparison ieee1588
|
||||
G.8275.defaultDS.localPriority 128
|
||||
#
|
||||
# Port Data Set
|
||||
#
|
||||
logAnnounceInterval -3
|
||||
logSyncInterval -4
|
||||
logMinDelayReqInterval -4
|
||||
logMinPdelayReqInterval -4
|
||||
announceReceiptTimeout 3
|
||||
syncReceiptTimeout 0
|
||||
delayAsymmetry 0
|
||||
fault_reset_interval -128
|
||||
neighborPropDelayThresh 20000000
|
||||
masterOnly 0
|
||||
G.8275.portDS.localPriority 128
|
||||
#
|
||||
# Run time options
|
||||
#
|
||||
assume_two_step 0
|
||||
logging_level 6
|
||||
path_trace_enabled 0
|
||||
follow_up_info 0
|
||||
hybrid_e2e 0
|
||||
inhibit_multicast_service 0
|
||||
net_sync_monitor 0
|
||||
tc_spanning_tree 0
|
||||
tx_timestamp_timeout 10
|
||||
unicast_listen 0
|
||||
unicast_master_table 0
|
||||
unicast_req_duration 3600
|
||||
use_syslog 1
|
||||
verbose 0
|
||||
summary_interval 0
|
||||
kernel_leap 1
|
||||
check_fup_sync 0
|
||||
#
|
||||
# Servo Options
|
||||
#
|
||||
pi_proportional_const 0.0
|
||||
pi_integral_const 0.0
|
||||
pi_proportional_scale 0.0
|
||||
pi_proportional_exponent -0.3
|
||||
pi_proportional_norm_max 0.7
|
||||
pi_integral_scale 0.0
|
||||
pi_integral_exponent 0.4
|
||||
pi_integral_norm_max 0.3
|
||||
step_threshold 0.0
|
||||
first_step_threshold 0.00002
|
||||
max_frequency 900000000
|
||||
clock_servo pi
|
||||
sanity_freq_limit 200000000
|
||||
ntpshm_segment 0
|
||||
#
|
||||
# Transport options
|
||||
#
|
||||
transportSpecific 0x0
|
||||
ptp_dst_mac 01:1B:19:00:00:00
|
||||
p2p_dst_mac 01:80:C2:00:00:0E
|
||||
udp_ttl 1
|
||||
udp6_scope 0x0E
|
||||
uds_address /var/run/ptp4l
|
||||
#
|
||||
# Default interface options
|
||||
#
|
||||
clock_type OC
|
||||
network_transport UDPv4
|
||||
delay_mechanism E2E
|
||||
time_stamping hardware
|
||||
tsproc_mode filter
|
||||
delay_filter moving_median
|
||||
delay_filter_length 10
|
||||
egressLatency 0
|
||||
ingressLatency 0
|
||||
boundary_clock_jbod 0
|
||||
#
|
||||
# Clock description
|
||||
#
|
||||
productDescription ;;
|
||||
revisionData ;;
|
||||
manufacturerIdentity 00:00:00
|
||||
userDescription ;
|
||||
timeSource 0xA0
|
||||
ptpClockThreshold: <6>
|
||||
holdOverTimeout: 5
|
||||
maxOffsetThreshold: 100
|
||||
minOffsetThreshold: -100
|
||||
recommend:
|
||||
- profile: "slave"
|
||||
priority: 4
|
||||
match:
|
||||
- nodeLabel: "node-role.kubernetes.io/<mcp-role>" <5>
|
||||
----
|
||||
<1> Name of the network interface that connects to the upstream PTP leader clock, for example, `ens787f1`.
|
||||
<2> Set `--summary_interval` to `-4` to use PTP fast events.
|
||||
<3> Scheduling policy for `ptp4l` and `phc2sys` processes. Default value is `SCHED_OTHER`. Use `SCHED_FIFO` on systems that support FIFO scheduling.
|
||||
<4> Integer value from 1-65 used to set FIFO priority for `ptp4l` and `phc2sys` processes. Required if `SCHED_FIFO` is set for `ptpSchedulingPolicy`.
|
||||
<5> `MachineConfig` node role that corresponds to the cluster nodes where the Columbiaville NICs are installed, for example, `worker-cnf`.
|
||||
<6> Optional. If `ptpClockThreshold` stanza is not present, default values are used for `ptpClockThreshold` fields. Stanza shows default `ptpClockThreshold` values.
|
||||
|
||||
.. Create the `PtpConfig` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f cvl-ptp-ordinary-clock.yaml
|
||||
----
|
||||
|
||||
.Verification steps
|
||||
|
||||
. Check that the `PtpConfig` profile is applied to the node.
|
||||
|
||||
.. Get the list of pods in the `openshift-ptp` namespace by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get pods -n openshift-ptp -o wide
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com
|
||||
linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com
|
||||
ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
|
||||
----
|
||||
|
||||
.. Check that the profile is correct. Examine the logs of the `linuxptp` daemon that corresponds to the node you specified in the `PtpConfig` profile. Run the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
|
||||
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
|
||||
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
|
||||
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
|
||||
I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
|
||||
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s --summary_interval -4
|
||||
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
|
||||
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
|
||||
----
|
||||
@@ -16,51 +16,53 @@ To start using PTP fast event notifications for a network interface in your clus
|
||||
|
||||
.Procedure
|
||||
|
||||
. Modify the `spec.ptpEventConfig` field of the `PtpOperatorConfig` resource and set appropriate values by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc edit PtpOperatorConfig default -n openshift-ptp
|
||||
----
|
||||
. Modify the default PTP Operator config to enable PTP fast events.
|
||||
|
||||
.. Save the following YAML in the `ptp-operatorconfig.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
...
|
||||
apiVersion: ptp.openshift.io/v1
|
||||
kind: PtpOperatorConfig
|
||||
metadata:
|
||||
name: default
|
||||
namespace: openshift-ptp
|
||||
spec:
|
||||
daemonNodeSelector:
|
||||
node-role.kubernetes.io/worker: ""
|
||||
node-role.kubernetes.io/worker: ""
|
||||
ptpEventConfig:
|
||||
enableEventPublisher: true <1>
|
||||
transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local <2>
|
||||
----
|
||||
<1> Set `enableEventPublisher` to `true` to enable PTP fast event notifications.
|
||||
<2> Set `transportHost` to the AMQ router you configured where `<instance_name>` and `<namespace>` correspond to the AMQ Interconnect router instance name and namespace, for example, `amqp://amq-interconnect.amq-interconnect.svc.cluster.local`
|
||||
<2> Set `transportHost` to the AMQ router that you configured where `<instance_name>` and `<namespace>` correspond to the AMQ Interconnect router instance name and namespace, for example, `amqp://amq-interconnect.amq-interconnect.svc.cluster.local`
|
||||
|
||||
. Create a `PtpConfig` custom resource for the PTP enabled interface, and set the required values for `ptpClockThreshold`, for example:
|
||||
.. Update the `PtpOperatorConfig` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f ptp-operatorconfig.yaml
|
||||
----
|
||||
|
||||
. Create a `PtpConfig` custom resource (CR) for the PTP enabled interface, and set the required values for `ptpClockThreshold` and `ptp4lOpts`. The following YAML illustrates the required values that you must set in the `PtpConfig` CR:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: ptp.openshift.io/v1
|
||||
kind: PtpConfig
|
||||
metadata:
|
||||
name: example-ptpconfig
|
||||
namespace: openshift-ptp
|
||||
spec:
|
||||
profile:
|
||||
- name: "profile1"
|
||||
interface: "enp5s0f0"
|
||||
ptp4lOpts: "-2 -s --summary_interval -4"
|
||||
ptp4lOpts: "-2 -s --summary_interval -4" <1>
|
||||
phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
|
||||
ptpClockThreshold:
|
||||
holdOverTimeout: 5 <1>
|
||||
maxOffsetThreshold: 100 <2>
|
||||
minOffsetThreshold: -100 <3>
|
||||
recommend:
|
||||
- profile: "profile1"
|
||||
priority: 4
|
||||
match:
|
||||
- nodeLabel: "node-role.kubernetes.io/worker"
|
||||
ptp4lConf: "" <2>
|
||||
ptpClockThreshold: <3>
|
||||
holdOverTimeout: 5 <4>
|
||||
maxOffsetThreshold: 100 <5>
|
||||
minOffsetThreshold: -100 <6>
|
||||
----
|
||||
<1> Number of seconds to stay in the clock holdover state. Holdover state is the period between local and master clock synchronizations.
|
||||
<2> Maximum offset value in nanoseconds. Offset is the time difference between the local and master clock.
|
||||
<3> Minimum offset value in nanoseconds.
|
||||
<1> Append `--summary_interval -4` to use PTP fast events.
|
||||
<2> Specify a string that contains the configuration to replace the default /etc/ptp4l.conf file. To use the default configuration, leave the field empty.
|
||||
<3> Optional. If `ptpClockThreshold` stanza is not present, default values are used for `ptpClockThreshold` fields. Stanza shows default `ptpClockThreshold` values.
|
||||
<4> Number of seconds to stay in the clock holdover state. Holdover state is the period between local and master clock synchronizations.
|
||||
<5> Maximum offset value in nanoseconds. Offset is the time difference between the local and master clock.
|
||||
<6> Minimum offset value in nanoseconds.
|
||||
|
||||
@@ -22,9 +22,9 @@ The PTP fast events notifications REST API is served at `http://localhost:8080/`
|
||||
- `POST`: Creates a new subscription
|
||||
- `GET`: Retrieves a list of subscriptions
|
||||
* `/api/cloudNotifications/v1/subscriptions/<subscription_id>`
|
||||
- `GET`: Creates a new status ping request for the specified subscription id
|
||||
- `GET`: Returns details for the specified subscription ID
|
||||
* `api/cloudNotifications/v1/subscriptions/status/<subscription_id>`
|
||||
- `PUT`: Creates a new status ping request for the specified subscription id
|
||||
- `PUT`: Creates a new status ping request for the specified subscription ID
|
||||
* `/api/cloudNotifications/v1/health`
|
||||
- `GET`: Returns the health status of `cloudNotifications` API
|
||||
|
||||
@@ -50,22 +50,18 @@ Creates a new publisher. If publisher creation is successful, or if it already e
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"id": "56e8a064-dc4b-4428-8085-91c18ea07930",
|
||||
"endpointUri": "http://localhost:8080/api/cloudNotifications/v1/dummy",
|
||||
"uriLocation": "http://localhost:8080/api/cloudNotifications/v1/publishers/56e8a064-dc4b-4428-8085-91c18ea07930",
|
||||
"uriLocation": "http://localhost:8080/api/cloudNotifications/v1/publishers",
|
||||
"resource": "/cluster/node/compute-1.example.com/ptp"
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
.Example oc exec curl command
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc exec -it linuxptp-daemon-5j265 -n openshift-ptp -c cloud-event-proxy -- curl --location --request POST 'http://localhost:8080/api/cloudNotifications/v1/publishers' --header 'Content-Type: application/json' --insecure --data ' {
|
||||
"id": "56e8a064-dc4b-4428-8085-91c18ea07930",
|
||||
"endpointUri": "http://localhost:8080/api/cloudNotifications/v1/dummy",
|
||||
"uriLocation": "http://localhost:8080/api/cloudNotifications/v1/publishers/56e8a064-dc4b-4428-8085-91c18ea07930",
|
||||
$ oc exec -it linuxptp-daemon-5j265 -n openshift-ptp -c cloud-event-proxy -- curl --location --request POST 'http://localhost:8080/api/cloudNotifications/v1/publishers' --header 'Content-Type: application/json' --insecure --data '{
|
||||
"uriLocation": "http://localhost:8080/api/cloudNotifications/v1/publishers",
|
||||
"resource": "/cluster/node/compute-1.example.com/ptp"
|
||||
}'
|
||||
}'
|
||||
----
|
||||
|
||||
=== HTTP method
|
||||
@@ -103,7 +99,7 @@ $ oc exec -it linuxptp-daemon-5j265 -n openshift-ptp -c cloud-event-proxy -- cur
|
||||
|
||||
==== Description
|
||||
|
||||
Returns the publisher with id `<publisher_id>`.
|
||||
Returns the publisher with ID `<publisher_id>`.
|
||||
|
||||
.Query parameters
|
||||
|===
|
||||
@@ -179,21 +175,17 @@ Creates a new subscription. If a subscription is successfully created, or if it
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"id": "56e8a064-dc4b-4428-8085-91c18ea07930",
|
||||
"endpointUri": "http://localhost:8080/api/cloudNotifications/v1/dummy",
|
||||
"uriLocation": "http://localhost:8080/api/cloudNotifications/v1/subscriptions/56e8a064-dc4b-4428-8085-91c18ea07930",
|
||||
"uriLocation": "http://localhost:8080/api/cloudNotifications/v1/subscriptions",
|
||||
"resource": "/cluster/node/compute-1.example.com/ptp"
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
.Example oc exec curl command
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc exec -it linuxptp-daemon-5j265 -n openshift-ptp -c cloud-event-proxy -- curl --location --request POST 'http://localhost:8080/api/cloudNotifications/v1/subscriptions' --header 'Content-Type: application/json' --insecure --data ' {
|
||||
"id": "56e8a064-dc4b-4428-8085-91c18ea07930",
|
||||
"endpointUri": "http://localhost:8080/api/cloudNotifications/v1/dummy",
|
||||
"uriLocation": "http://localhost:8080/api/cloudNotifications/v1/subscriptions/75b1ad8f-dc4b-4428-8085-91c18ea07930",
|
||||
"resource": "/cluster/node/compute-1.example.com/ptp"
|
||||
$ oc exec -it linuxptp-daemon-5j265 -n openshift-ptp -c cloud-event-proxy -- curl --location --request POST 'http://localhost:8080/api/cloudNotifications/v1/subscriptions' --header 'Content-Type: application/json' --insecure --data '{
|
||||
"uriLocation": "http://localhost:8080/api/cloudNotifications/v1/subscriptions",
|
||||
"resource": "/cluster/node/compute-1.example.com/ptp"
|
||||
}'
|
||||
----
|
||||
|
||||
@@ -205,7 +197,7 @@ $ oc exec -it linuxptp-daemon-5j265 -n openshift-ptp -c cloud-event-proxy -- cur
|
||||
|
||||
==== Description
|
||||
|
||||
Returns details for the subscription with id `<subscription_id>`
|
||||
Returns details for the subscription with ID `<subscription_id>`
|
||||
|
||||
.Query parameters
|
||||
|===
|
||||
@@ -224,7 +216,12 @@ $ oc exec -it linuxptp-daemon-5j265 -n openshift-ptp -c cloud-event-proxy -- cur
|
||||
.Example return
|
||||
[source,terminal]
|
||||
----
|
||||
{"id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab","endpointUri":"http://localhost:8080/api/cloudNotifications/v1/dummy","uriLocation":"http://localhost:8080/api/cloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab","resource":"/cluster/node/compute-1.example.com/ptp"}
|
||||
{
|
||||
"id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab",
|
||||
"endpointUri":"http://localhost:8080/api/cloudNotifications/v1/dummy",
|
||||
"uriLocation":"http://localhost:8080/api/cloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab",
|
||||
"resource":"/cluster/node/compute-1.example.com/ptp"
|
||||
}
|
||||
----
|
||||
|
||||
== api/cloudNotifications/v1/subscriptions/status/<subscription_id>
|
||||
@@ -235,7 +232,7 @@ $ oc exec -it linuxptp-daemon-5j265 -n openshift-ptp -c cloud-event-proxy -- cur
|
||||
|
||||
==== Description
|
||||
|
||||
Creates a new status ping request for subscription with id `<subscription_id>`. If a subscription is present, the status request is successful and a `202 Accepted` status code is returned.
|
||||
Creates a new status ping request for subscription with ID `<subscription_id>`. If a subscription is present, the status request is successful and a `202 Accepted` status code is returned.
|
||||
|
||||
.Query parameters
|
||||
|===
|
||||
|
||||
@@ -4,10 +4,14 @@
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="configuring-linuxptp-services-as-boundary-clock_{context}"]
|
||||
= Configuring linuxptp services as boundary clock
|
||||
= Configuring linuxptp services as a boundary clock
|
||||
|
||||
The PTP Operator adds the `PtpConfig.ptp.openshift.io` custom resource definition (CRD) to {product-title}.
|
||||
You can configure the `linuxptp` services (`ptp4l`, `phc2sys`) by creating a `PtpConfig` custom resource (CR) object.
|
||||
You can configure the `linuxptp` services (`ptp4l`, `phc2sys`) as boundary clock by creating a `PtpConfig` custom resource (CR) object.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The following `PtpConfig` CR configures PTP fast events by setting values for `ptp4lOpts`, `ptp4lConf` and `ptpClockThreshold`.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -30,7 +34,7 @@ spec:
|
||||
profile: <2>
|
||||
- name: "profile1" <3>
|
||||
interface: "" <4>
|
||||
ptp4lOpts: "-2" <5>
|
||||
ptp4lOpts: "-2 -s --summary_interval -4" <5>
|
||||
ptp4lConf: | <6>
|
||||
[ens1f0] <7>
|
||||
masterOnly 0
|
||||
@@ -140,12 +144,16 @@ spec:
|
||||
phc2sysOpts: "-a -r" <9>
|
||||
ptpSchedulingPolicy: SCHED_OTHER <10>
|
||||
ptpSchedulingPriority: 65 <11>
|
||||
recommend: <12>
|
||||
- profile: "profile1" <13>
|
||||
priority: 10 <14>
|
||||
match: <15>
|
||||
- nodeLabel: "node-role.kubernetes.io/worker" <16>
|
||||
nodeName: "compute-0.example.com" <17>
|
||||
ptpClockThreshold: <12>
|
||||
holdOverTimeout: 5
|
||||
maxOffsetThreshold: 100
|
||||
minOffsetThreshold: -100
|
||||
recommend: <13>
|
||||
- profile: "profile1" <14>
|
||||
priority: 10 <15>
|
||||
match: <16>
|
||||
- nodeLabel: "node-role.kubernetes.io/worker" <17>
|
||||
nodeName: "compute-0.example.com" <18>
|
||||
----
|
||||
<1> The name of the `PtpConfig` CR.
|
||||
<2> Specify an array of one or more `profile` objects.
|
||||
@@ -153,17 +161,18 @@ spec:
|
||||
<4> This field should remain empty for boundary clock.
|
||||
<5> Specify system config options for the `ptp4l` service, for example `-2`. The options should not include the network interface name `-i <interface>` and service config file `-f /etc/ptp4l.conf` because the network interface name and the service config file are automatically appended.
|
||||
<6> Specify the needed configuration to start `ptp4l` as boundary clock. For example, `ens1f0` synchronizes from a grandmaster clock and `ens1f3` synchronizes connected devices.
|
||||
<7> The interface name to synchronize from.
|
||||
<8> The interface to synchronize devices connected to the interface.
|
||||
<7> The interface that receives the synchronization clock.
|
||||
<8> The interface that synchronizes downstream connected devices.
|
||||
<9> Specify system config options for the `phc2sys` service, for example `-a -r`. If this field is empty the PTP Operator does not start the `phc2sys` service.
|
||||
<10> Scheduling policy for ptp4l and phc2sys processes. Default value is `SCHED_OTHER`. Use `SCHED_FIFO` on systems that support FIFO scheduling.
|
||||
<11> Integer value from 1-65 used to set FIFO priority for `ptp4l` and `phc2sys` processes. Required if `SCHED_FIFO` is set for `ptpSchedulingPolicy`.
|
||||
<12> Specify an array of one or more `recommend` objects that define rules on how the `profile` should be applied to nodes.
|
||||
<13> Specify the `profile` object name defined in the `profile` section.
|
||||
<14> Specify the `priority` with an integer value between `0` and `99`. A larger number gets lower priority, so a priority of `99` is lower than a priority of `10`. If a node can be matched with multiple profiles according to rules defined in the `match` field, the profile with the higher priority is applied to that node.
|
||||
<15> Specify `match` rules with `nodeLabel` or `nodeName`.
|
||||
<16> Specify `nodeLabel` with the `key` of `node.Labels` from the node object.
|
||||
<17> Specify `nodeName` with `node.Name` from the node object.
|
||||
<12> Optional. If `ptpClockThreshold` stanza is not present, default values are used for `ptpClockThreshold` fields. Stanza shows default `ptpClockThreshold` values.
|
||||
<13> Specify an array of one or more `recommend` objects that define rules on how the `profile` should be applied to nodes.
|
||||
<14> Specify the `profile` object name defined in the `profile` section.
|
||||
<15> Specify the `priority` with an integer value between `0` and `99`. A larger number gets lower priority, so a priority of `99` is lower than a priority of `10`. If a node can be matched with multiple profiles according to rules defined in the `match` field, the profile with the higher priority is applied to that node.
|
||||
<16> Specify `match` rules with `nodeLabel` or `nodeName`.
|
||||
<17> Specify `nodeLabel` with the `key` of `node.Labels` from the node object.
|
||||
<18> Specify `nodeName` with `node.Name` from the node object.
|
||||
|
||||
. Create the CR by running the following command:
|
||||
+
|
||||
@@ -207,7 +216,7 @@ I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
|
||||
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
|
||||
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
|
||||
I1115 09:41:17.117616 4143292 daemon.go:102] Interface:
|
||||
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2
|
||||
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s --summary_interval -4
|
||||
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r
|
||||
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
|
||||
----
|
||||
|
||||
@@ -4,10 +4,14 @@
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="configuring-linuxptp-services-as-ordinary-clock_{context}"]
|
||||
= Configuring linuxptp services as ordinary clock
|
||||
= Configuring linuxptp services as an ordinary clock
|
||||
|
||||
The PTP Operator adds the `PtpConfig.ptp.openshift.io` custom resource definition (CRD) to {product-title}.
|
||||
You can configure the `linuxptp` services (`ptp4l`, `phc2sys`) by creating a `PtpConfig` custom resource (CR) object.
|
||||
You can configure `linuxptp` services (`ptp4l`, `phc2sys`) as ordinary clock by creating a `PtpConfig` custom resource (CR) object.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The following `PtpConfig` CR configures PTP fast events by setting values for `ptp4lOpts`, `ptp4lConf` and `ptpClockThreshold`.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -30,35 +34,140 @@ spec:
|
||||
profile: <2>
|
||||
- name: "profile1" <3>
|
||||
interface: "ens787f1" <4>
|
||||
ptp4lOpts: "-s -2" <5>
|
||||
phc2sysOpts: "-a -r" <6>
|
||||
ptp4lConf: "" <7>
|
||||
ptp4lOpts: "-2 -s --summary_interval -4" <5>
|
||||
phc2sysOpts: "-a -r -n 24" <6>
|
||||
ptp4lConf: | <7>
|
||||
[global]
|
||||
#
|
||||
# Default Data Set
|
||||
#
|
||||
twoStepFlag 1
|
||||
slaveOnly 0
|
||||
priority1 128
|
||||
priority2 128
|
||||
domainNumber 24
|
||||
#utc_offset 37
|
||||
clockClass 248
|
||||
clockAccuracy 0xFE
|
||||
offsetScaledLogVariance 0xFFFF
|
||||
free_running 0
|
||||
freq_est_interval 1
|
||||
dscp_event 0
|
||||
dscp_general 0
|
||||
dataset_comparison ieee1588
|
||||
G.8275.defaultDS.localPriority 128
|
||||
#
|
||||
# Port Data Set
|
||||
#
|
||||
logAnnounceInterval -3
|
||||
logSyncInterval -4
|
||||
logMinDelayReqInterval -4
|
||||
logMinPdelayReqInterval -4
|
||||
announceReceiptTimeout 3
|
||||
syncReceiptTimeout 0
|
||||
delayAsymmetry 0
|
||||
fault_reset_interval 4
|
||||
neighborPropDelayThresh 20000000
|
||||
masterOnly 0
|
||||
G.8275.portDS.localPriority 128
|
||||
#
|
||||
# Run time options
|
||||
#
|
||||
assume_two_step 0
|
||||
logging_level 6
|
||||
path_trace_enabled 0
|
||||
follow_up_info 0
|
||||
hybrid_e2e 0
|
||||
inhibit_multicast_service 0
|
||||
net_sync_monitor 0
|
||||
tc_spanning_tree 0
|
||||
tx_timestamp_timeout 1
|
||||
unicast_listen 0
|
||||
unicast_master_table 0
|
||||
unicast_req_duration 3600
|
||||
use_syslog 1
|
||||
verbose 0
|
||||
summary_interval 0
|
||||
kernel_leap 1
|
||||
check_fup_sync 0
|
||||
#
|
||||
# Servo Options
|
||||
#
|
||||
pi_proportional_const 0.0
|
||||
pi_integral_const 0.0
|
||||
pi_proportional_scale 0.0
|
||||
pi_proportional_exponent -0.3
|
||||
pi_proportional_norm_max 0.7
|
||||
pi_integral_scale 0.0
|
||||
pi_integral_exponent 0.4
|
||||
pi_integral_norm_max 0.3
|
||||
step_threshold 0.0
|
||||
first_step_threshold 0.00002
|
||||
max_frequency 900000000
|
||||
clock_servo pi
|
||||
sanity_freq_limit 200000000
|
||||
ntpshm_segment 0
|
||||
#
|
||||
# Transport options
|
||||
#
|
||||
transportSpecific 0x0
|
||||
ptp_dst_mac 01:1B:19:00:00:00
|
||||
p2p_dst_mac 01:80:C2:00:00:0E
|
||||
udp_ttl 1
|
||||
udp6_scope 0x0E
|
||||
uds_address /var/run/ptp4l
|
||||
#
|
||||
# Default interface options
|
||||
#
|
||||
clock_type OC
|
||||
network_transport UDPv4
|
||||
delay_mechanism E2E
|
||||
time_stamping hardware
|
||||
tsproc_mode filter
|
||||
delay_filter moving_median
|
||||
delay_filter_length 10
|
||||
egressLatency 0
|
||||
ingressLatency 0
|
||||
boundary_clock_jbod 0
|
||||
#
|
||||
# Clock description
|
||||
#
|
||||
productDescription ;;
|
||||
revisionData ;;
|
||||
manufacturerIdentity 00:00:00
|
||||
userDescription ;
|
||||
timeSource 0xA0
|
||||
ptpSchedulingPolicy: SCHED_OTHER <8>
|
||||
ptpSchedulingPriority: 65 <9>
|
||||
recommend: <10>
|
||||
- profile: "profile1" <11>
|
||||
priority: 10 <12>
|
||||
match: <13>
|
||||
- nodeLabel: "node-role.kubernetes.io/worker" <14>
|
||||
nodeName: "compute-0.example.com" <15>
|
||||
ptpClockThreshold: <10>
|
||||
holdOverTimeout: 5
|
||||
maxOffsetThreshold: 100
|
||||
minOffsetThreshold: -100
|
||||
recommend: <11>
|
||||
- profile: "profile1" <12>
|
||||
priority: 10 <13>
|
||||
match: <14>
|
||||
- nodeLabel: "node-role.kubernetes.io/worker" <15>
|
||||
nodeName: "compute-0.example.com" <16>
|
||||
----
|
||||
<1> The name of the `PtpConfig` CR.
|
||||
<2> Specify an array of one or more `profile` objects.
|
||||
<3> Specify the name of a profile object that uniquely identifies a profile object.
|
||||
<4> Specify the network interface name to use by the `ptp4l` service, for example `ens787f1`.
|
||||
<5> Specify system config options for the `ptp4l` service, for example `-2` to select the IEEE 802.3 network transport. The options should not include the network interface name `-i <interface>` and service config file `-f /etc/ptp4l.conf` because the network interface name and the service config file are automatically appended.
|
||||
<6> Specify system config options for the `phc2sys` service, for example `-a -r`. If this field is empty the PTP Operator does not start the `phc2sys` service.
|
||||
<3> Specify a unique name for the profile object.
|
||||
<4> Specify the network interface to be used by the `ptp4l` service, for example `ens787f1`.
|
||||
<5> Specify system config options for the `ptp4l` service, for example `-2` to select the IEEE 802.3 network transport. The options should not include the network interface name `-i <interface>` and service config file `-f /etc/ptp4l.conf` because the network interface name and the service config file are automatically appended. Append `--summary_interval -4` to use PTP fast events with this interface.
|
||||
<6> Specify system config options for the `phc2sys` service, for example `-a -r -n 24`. If this field is empty the PTP Operator does not start the `phc2sys` service.
|
||||
<7> Specify a string that contains the configuration to replace the default `/etc/ptp4l.conf` file. To use the default configuration, leave the field empty.
|
||||
<8> Scheduling policy for `ptp4l` and `phc2sys` processes. Default value is `SCHED_OTHER`. Use `SCHED_FIFO` on systems that support FIFO scheduling.
|
||||
<9> Integer value from 1-65 used to set FIFO priority for `ptp4l` and `phc2sys` processes. Required if `SCHED_FIFO` is set for `ptpSchedulingPolicy`.
|
||||
<10> Specify an array of one or more `recommend` objects that define rules on how the `profile` should be applied to nodes.
|
||||
<11> Specify the `profile` object name defined in the `profile` section.
|
||||
<12> Specify the `priority` with an integer value between `0` and `99`. A larger number gets lower priority, so a priority of `99` is lower than a priority of `10`. If a node can be matched with multiple profiles according to rules defined in the `match` field, the profile with the higher priority is applied to that node.
|
||||
<13> Specify `match` rules with `nodeLabel` or `nodeName`.
|
||||
<14> Specify `nodeLabel` with the `key` of `node.Labels` from the node object.
|
||||
<15> Specify `nodeName` with `node.Name` from the node object.
|
||||
<10> Optional. If `ptpClockThreshold` stanza is not present, default values are used for `ptpClockThreshold` fields. Stanza shows default `ptpClockThreshold` values.
|
||||
<11> Specify an array of one or more `recommend` objects that define rules on how the `profile` should be applied to nodes.
|
||||
<12> Specify the `profile` object name defined in the `profile` section.
|
||||
<13> Specify the `priority` with an integer value between `0` and `99`. A larger number gets lower priority, so a priority of `99` is lower than a priority of `10`. If a node can be matched with multiple profiles according to rules defined in the `match` field, the profile with the higher priority is applied to that node.
|
||||
<14> Specify `match` rules with `nodeLabel` or `nodeName`.
|
||||
<15> Specify `nodeLabel` with the `key` of `node.Labels` from the node object.
|
||||
<16> Specify `nodeName` with `node.Name` from the node object.
|
||||
|
||||
. Create the CR by running the following command:
|
||||
. Create the `PtpConfig` CR by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -100,7 +209,7 @@ I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
|
||||
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
|
||||
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
|
||||
I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
|
||||
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -s -2
|
||||
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s --summary_interval -4
|
||||
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r
|
||||
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
|
||||
----
|
||||
|
||||
@@ -2,49 +2,42 @@
|
||||
//
|
||||
// * networking/using-ptp.adoc
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="discover-ptp-devices_{context}"]
|
||||
= Automated discovery of PTP network devices
|
||||
|
||||
The PTP Operator adds the `NodePtpDevice.ptp.openshift.io` custom resource definition (CRD) to {product-title}.
|
||||
|
||||
The PTP Operator searchs 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 device.
|
||||
|
||||
One CR is created for each node and shares the same name as the node. The `.status.devices` list provides information about the PTP devices on a node.
|
||||
|
||||
The following is an example of a `NodePtpDevice` CR created by the PTP Operator:
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: ptp.openshift.io/v1
|
||||
kind: NodePtpDevice
|
||||
metadata:
|
||||
creationTimestamp: "2019-11-15T08:57:11Z"
|
||||
generation: 1
|
||||
name: dev-worker-0 <1>
|
||||
namespace: openshift-ptp <2>
|
||||
resourceVersion: "487462"
|
||||
selfLink: /apis/ptp.openshift.io/v1/namespaces/openshift-ptp/nodeptpdevices/dev-worker-0
|
||||
uid: 08d133f7-aae2-403f-84ad-1fe624e5ab3f
|
||||
spec: {}
|
||||
status:
|
||||
devices: <3>
|
||||
- name: eno1
|
||||
- name: eno2
|
||||
- name: ens787f0
|
||||
- name: ens787f1
|
||||
- name: ens801f0
|
||||
- name: ens801f1
|
||||
- name: ens802f0
|
||||
- name: ens802f1
|
||||
- name: ens803
|
||||
----
|
||||
<1> The value for the `name` parameter is the same as the name of the node.
|
||||
<2> The CR is created in `openshift-ptp` namespace by PTP Operator.
|
||||
<3> The `devices` collection includes a list of the PTP capable devices discovered by the Operator on the node.
|
||||
|
||||
To return a complete list of PTP capable network devices in your cluster, run the following command:
|
||||
= Discovering PTP capable network devices in your cluster
|
||||
|
||||
* To return a complete list of PTP capable network devices in your cluster, run the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get NodePtpDevice -n openshift-ptp -o yaml
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
apiVersion: v1
|
||||
items:
|
||||
- apiVersion: ptp.openshift.io/v1
|
||||
kind: NodePtpDevice
|
||||
metadata:
|
||||
creationTimestamp: "2022-01-27T15:16:28Z"
|
||||
generation: 1
|
||||
name: dev-worker-0 <1>
|
||||
namespace: openshift-ptp
|
||||
resourceVersion: "6538103"
|
||||
uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a
|
||||
spec: {}
|
||||
status:
|
||||
devices: <2>
|
||||
- name: eno1
|
||||
- name: eno2
|
||||
- name: eno3
|
||||
- name: eno4
|
||||
- name: enp5s0f0
|
||||
- name: enp5s0f1
|
||||
...
|
||||
----
|
||||
<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.
|
||||
|
||||
|
||||
@@ -16,11 +16,12 @@ As a cluster administrator, you can install the Operator by using the CLI.
|
||||
|
||||
.Procedure
|
||||
|
||||
. To create a namespace for the PTP Operator, enter the following command:
|
||||
. Create a namespace for the PTP Operator.
|
||||
|
||||
.. Save the following YAML in the `ptp-namespace.yaml` file:
|
||||
+
|
||||
[source,terminal]
|
||||
[source,yaml]
|
||||
----
|
||||
$ cat << EOF| oc create -f -
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
@@ -30,14 +31,21 @@ metadata:
|
||||
labels:
|
||||
name: openshift-ptp
|
||||
openshift.io/cluster-monitoring: "true"
|
||||
EOF
|
||||
----
|
||||
|
||||
. To create an Operator group for the Operator, enter the following command:
|
||||
.. Create the `Namespace` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ cat << EOF| oc create -f -
|
||||
$ oc create -f ptp-namespace.yaml
|
||||
----
|
||||
|
||||
. Create an Operator group for the PTP Operator.
|
||||
|
||||
.. Save the following YAML in the `ptp-operatorgroup.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: operators.coreos.com/v1
|
||||
kind: OperatorGroup
|
||||
metadata:
|
||||
@@ -46,49 +54,50 @@ metadata:
|
||||
spec:
|
||||
targetNamespaces:
|
||||
- openshift-ptp
|
||||
EOF
|
||||
----
|
||||
|
||||
.. Create the `OperatorGroup` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f ptp-operatorgroup.yaml
|
||||
----
|
||||
|
||||
. Subscribe to the PTP Operator.
|
||||
|
||||
.. Run the following command to set the {product-title} major and minor version as an environment variable, which is used as the `channel` value in the next
|
||||
step.
|
||||
.. Save the following YAML in the `ptp-sub.yaml` file:
|
||||
+
|
||||
[source,terminal]
|
||||
[source,yaml]
|
||||
----
|
||||
$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
|
||||
grep -o '[0-9]*[.][0-9]*' | head -1)
|
||||
----
|
||||
|
||||
.. To create a subscription for the PTP Operator, enter the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ cat << EOF| oc create -f -
|
||||
apiVersion: operators.coreos.com/v1alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: ptp-operator-subscription
|
||||
namespace: openshift-ptp
|
||||
spec:
|
||||
channel: "${OC_VERSION}"
|
||||
channel: "stable"
|
||||
name: ptp-operator
|
||||
source: redhat-operators
|
||||
sourceNamespace: openshift-marketplace
|
||||
EOF
|
||||
----
|
||||
|
||||
.. Create the `Subscription` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f ptp-sub.yaml
|
||||
----
|
||||
|
||||
. To verify that the Operator is installed, enter the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get csv -n openshift-ptp \
|
||||
-o custom-columns=Name:.metadata.name,Phase:.status.phase
|
||||
$ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
Name Phase
|
||||
ptp-operator.4.4.0-202006160135 Succeeded
|
||||
Name Phase
|
||||
4.10.0-202201261535 Succeeded
|
||||
----
|
||||
|
||||
@@ -6,16 +6,16 @@
|
||||
[id="ptp-introduction_{context}"]
|
||||
= About PTP
|
||||
|
||||
The 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).
|
||||
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).
|
||||
|
||||
The `linuxptp` package includes the `ptp4l` and `phc2sys` programs for clock synchronization. `ptp4l` implements the PTP boundary clock and ordinary clock. `ptp4l` synchronizes the PTP hardware clock to the source clock with hardware time stamping and synchronizes the system clock to the source clock with software time stamping. `phc2sys` is used for hardware time stamping to synchronize the system clock to the PTP hardware clock on the network interface controller (NIC).
|
||||
|
||||
[id="ptp-elements_{context}"]
|
||||
== Elements of a PTP domain
|
||||
|
||||
PTP is used to synchronize multiple nodes connected in a network, with clocks for each node. The following type of clocks can be included in configurations:
|
||||
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 following types of clocks can be included in configurations:
|
||||
|
||||
Grandmaster clock:: The grandmaster clock provides standard time information to other clocks across the network and ensures accurate and stable synchronisation. The grandmaster clock writes time stamps and responds to time requests from other clocks.
|
||||
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 can be synchronized to a Global Positioning System (GPS) time source.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
92
modules/ztp-configuring-ptp-fast-events.adoc
Normal file
92
modules/ztp-configuring-ptp-fast-events.adoc
Normal file
@@ -0,0 +1,92 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// scalability_and_performance/ztp-deploying-disconnected.adoc
|
||||
|
||||
:_module-type: PROCEDURE
|
||||
[id="ztp-configuring-ptp-fast-events_{context}"]
|
||||
= Configuring PTP fast events using PolicyGenTemplate custom resources and GitOps ZTP
|
||||
|
||||
You can configure PTP fast events for vRAN clusters that are deployed using the GitOps Zero Touch Provisioning (ZTP) pipeline. Use `PolicyGenTemplate` custom resources (CRs) as the basis to create a hierarchy of configuration files tailored to your specific site requirements.
|
||||
|
||||
The `PolicyGenTemplate` CRs that are relevant to PTP events can be found in the `/home/ztp/argocd/example` folder in the `quay.io/redhat_emp1/ztp-site-generator:latest` reference architecture container image. The reference architecture has a `/policygentemplates` and `/siteconfig` folder. The `/policygentemplates` folder has common, group, and site-specific configuration CRs. Each `PolicyGenTemplate` CR refers to other CRs that are in the `/source-crs` folder of the reference architecture.
|
||||
|
||||
The `PolicyGenTemplate` CRs required to deploy PTP fast events are described below.
|
||||
|
||||
.PolicyGenTemplate CRs for vRAN deployments
|
||||
[cols=2*, options="header"]
|
||||
|====
|
||||
|PolicyGenTemplate CR
|
||||
|Description
|
||||
|
||||
|`common-ranGen.yaml`
|
||||
|Contains the common RAN policies that get applied to all clusters. To deploy the PTP Operator to your clusters, you configure `Namespace`, `Subscription`, and `OperatorGroup` CRs.
|
||||
|
||||
|`group-du-3node-ranGen.yaml`
|
||||
|Contains the RAN policies for three-node clusters only, including PTP fast events configuration.
|
||||
|
||||
|`group-du-sno-ranGen.yaml`
|
||||
|Contains the RAN policies for single-node clusters only, including PTP fast events configuration.
|
||||
|
||||
|`group-du-standard-ranGen.yaml`
|
||||
|Contains the RAN policies for standard three control-plane clusters, including PTP fast events configuration.
|
||||
|====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* Create a Git repository where you manage your custom site configuration data.
|
||||
* Extract the contents of the `/home/ztp` folder from the `quay.io/redhat_emp1/ztp-site-generator:latest` reference architecture container image, and review the changes.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Add the following YAML into `.spec.sourceFiles` in the `common-ranGen.yaml` file to configure the AMQP Operator:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
#AMQ interconnect operator for fast events
|
||||
- fileName: AmqSubscriptionNS.yaml
|
||||
policyName: "amq-sub-policy"
|
||||
- fileName: AmqSubscriptionOperGroup.yaml
|
||||
policyName: "amq-sub-policy"
|
||||
- fileName: AmqSubscription.yaml
|
||||
policyName: "amq-sub-policy"
|
||||
----
|
||||
|
||||
. Apply the following `PolicyGenTemplate` changes to `group-du-3node-ranGen.yaml`, `group-du-sno-ranGen.yaml`, or `group-du-standard-ranGen.yaml` files according to your requirements:
|
||||
|
||||
.. In `.sourceFiles`, add the `PtpOperatorConfig` CR that configures the AMQ transport host to the `config-policy`:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
- fileName: PtpOperatorConfigForEvent.yaml
|
||||
policyName: "config-policy"
|
||||
----
|
||||
|
||||
.. Configure the `linuxptp` and `phc2sys` for the PTP clock type and interface. For example, add the following stanza into `.sourceFiles`:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
- fileName: PtpConfigSlave.yaml <1>
|
||||
policyName: "config-policy"
|
||||
metadata:
|
||||
name: "du-ptp-slave"
|
||||
spec:
|
||||
profile:
|
||||
- name: "slave"
|
||||
interface: "ens5f1" <2>
|
||||
ptp4lOpts: "-2 -s --summary_interval -4" <3>
|
||||
phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
|
||||
ptpClockThreshold: <4>
|
||||
holdOverTimeout: 30 #secs
|
||||
maxOffsetThreshold: 100 #nano secs
|
||||
minOffsetThreshold: -100 #nano secs
|
||||
----
|
||||
<1> Can be one `PtpConfigMaster.yaml`, `PtpConfigSlave.yaml`, or `PtpConfigSlaveCvl.yaml` depending on your requirements. `PtpConfigSlaveCvl.yaml` configes `linuxptp` services for an Intel E810 Columbiaville NIC.
|
||||
<2> Device specific interface name.
|
||||
<3> You must append the `--summary_interval -4` value to `ptp4lOpts` in `.spec.sourceFiles.spec.profile` to enable PTP fast events.
|
||||
<4> `ptpClockThreshold` configues how long the clock stays in clock holdover state. Holdover state is the period between local and master clock synchronizations. Offset is the time difference between the local and master clock.
|
||||
|
||||
. Merge any other required changes and files with your custom site repository.
|
||||
|
||||
. Push the changes to your site configuration repository to deploy PTP fast events to new sites using GitOps ZTP.
|
||||
|
||||
//. Optional: Use the Topology-Aware Lifecycle Operator to deploy PTP events to existing sites.
|
||||
@@ -6,6 +6,4 @@
|
||||
[id="ztp-precision-time-protocol-operator_{context}"]
|
||||
= Precision Time Protocol Operator
|
||||
|
||||
The Precision Time Protocol (PTP) Operator is a protocol used to synchronize clocks in a network. When used in conjunction with hardware support, PTP is capable of sub-microsecond accuracy. PTP support is divided between the kernel and user space.
|
||||
|
||||
The clocks synchronized by PTP are organized in a master-worker hierarchy. The workers are synchronized to their masters, which may be workers to their own masters. The hierarchy is created and updated automatically by the best master clock (BMC) algorithm, which runs on every clock. When a clock has only one port, it can be master or worker, such a clock is called an ordinary clock (OC). A clock with multiple ports can be master on one port and worker on another, such a clock is called a boundary clock (BC). The top-level master is called the grandmaster clock, which can be synchronized by using a Global Positioning System (GPS) time source. By using a GPS-based time source, disparate networks can be synchronized with a high-degree of accuracy.
|
||||
Precision Time Protocol (PTP) is used to synchronize clocks in a network. The PTP Operator discovers PTP-capable devices in the cluster and creates and manages `linuxptp` services for those devices. The PTP Operator also deploys a PTP fast events infrastructure. vDU applications use PTP fast events notifications to report on clock events that can negatively affect the performance and reliability of the application. PTP fast events are distributed over an Advanced Message Queuing Protocol (AMQP) event notification bus.
|
||||
|
||||
@@ -6,24 +6,24 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
:FeatureName: Precision Time Protocol (PTP) hardware
|
||||
:FeatureName: Precision Time Protocol (PTP) hardware with single NIC configured as boundary clock
|
||||
include::snippets/technology-preview.adoc[leveloffset=+1]
|
||||
|
||||
[id="about-using-ptp-hardware"]
|
||||
== About PTP hardware
|
||||
|
||||
{product-title} allows you use Precision Time Protocol (PTP) hardware on your nodes. You can configure linuxptp services on nodes that have PTP-capable hardware.
|
||||
You can configure `linuxptp` services and use PTP-capable hardware in {product-title} cluster nodes.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The PTP Operator works with PTP-capable devices on clusters provisioned only on bare-metal infrastructure.
|
||||
====
|
||||
|
||||
You can use the {product-title} console or `oc` CLI to install PTP by deploying the PTP Operator. The PTP Operator creates and manages the linuxptp services and provides the following features:
|
||||
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.
|
||||
* 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.
|
||||
|
||||
@@ -38,29 +38,47 @@ 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]
|
||||
== Configuring PTP devices
|
||||
|
||||
include::modules/nw-ptp-configuring-linuxptp-services-as-ordinary-clock.adoc[leveloffset=+1]
|
||||
The PTP Operator adds the `NodePtpDevice.ptp.openshift.io` custom resource definition (CRD) to {product-title}.
|
||||
|
||||
include::modules/nw-ptp-configuring-linuxptp-services-as-boundary-clock.adoc[leveloffset=+1]
|
||||
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/cnf-configuring-fifo-priority-scheduling-for-ptp.adoc[leveloffset=+1]
|
||||
include::modules/nw-ptp-device-discovery.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/nw-ptp-configuring-linuxptp-services-as-ordinary-clock.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/nw-ptp-configuring-linuxptp-services-as-boundary-clock.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-configuring-cvl-nic-as-oc.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-configuring-fifo-priority-scheduling-for-ptp.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-troubleshooting-common-ptp-operator-issues.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/cnf-about-ptp-and-clock-synchronization.adoc[leveloffset=+1]
|
||||
== PTP hardware fast event notifications framework
|
||||
|
||||
include::modules/cnf-about-ptp-fast-event-notifications-framework.adoc[leveloffset=+1]
|
||||
:FeatureName: PTP events with ordinary clock
|
||||
include::snippets/technology-preview.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-installing-amq-interconnect-messaging-bus.adoc[leveloffset=+1]
|
||||
include::modules/cnf-about-ptp-and-clock-synchronization.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-configuring-the-ptp-fast-event-publisher.adoc[leveloffset=+1]
|
||||
include::modules/cnf-about-ptp-fast-event-notifications-framework.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-fast-event-notifications-api-refererence.adoc[leveloffset=+1]
|
||||
include::modules/cnf-installing-amq-interconnect-messaging-bus.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-monitoring-fast-events-metrics-using-cli.adoc[leveloffset=+1]
|
||||
include::modules/cnf-configuring-the-ptp-fast-event-publisher.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-ptp-fast-event-metrics-in-prometheus.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* For a complete example CR that configures `linuxptp` services 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-fast-event-notifications-api-refererence.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-monitoring-fast-events-metrics-using-cli.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cnf-ptp-fast-event-metrics-in-prometheus.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
@@ -99,8 +99,25 @@ include::modules/ztp-sriov-operator.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/ztp-precision-time-protocol-operator.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
// New files for Creating ZTP custom resources for multiple managed clusters for 4.9
|
||||
* For more information about using PTP hardware in your cluster nodes, see xref:../networking/using-ptp.adoc#using-ptp[Using PTP hardware].
|
||||
|
||||
include::modules/ztp-configuring-ptp-fast-events.adoc[leveloffset=+2]
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
When changes are pushed to a site configuration repository, GitOps ZTP applies the CRs sequentially according to the `ran.openshift.io/ztp-deploy-wave` annotation. When two or more policies have the same `ran.openshift.io/ztp-deploy-wave` annotation, an alphanumeric sort order is used. For more information, see xref:../scalability_and_performance/ztp-deploying-disconnected.adoc#ztp-applying-the-ran-policies-for-monitoring-cluster-activity_ztp-deploying-disconnected[Applying RAN policies].
|
||||
====
|
||||
|
||||
.Additional resources
|
||||
|
||||
* For a complete `PtpConfig` CR that configures `linuxptp` as an ordinary clock, see xref:../networking/using-ptp.adoc#cnf-configuring-cvl-nic-as-ptp-slave_using-ptp[Configuring linuxptp services as an ordinary clock for Intel Columbiaville NIC].
|
||||
|
||||
* For further information about configuring PTP fast event notifications, see xref:../networking/using-ptp.adoc#cnf-configuring-the-ptp-fast-event-publisher_using-ptp[Configuring PTP fast events].
|
||||
|
||||
//../scalability_and_performance/cnf-topology-aware-lifecycle-operator.adoc#talo-apply-policies_cnf-topology-aware-lifecycle-operator[Applying update policies to managed clusters with the Topology Aware Lifecycle Operator]
|
||||
|
||||
include::modules/ztp-creating-ztp-custom-resources-for-multiple-managed-clusters.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
Reference in New Issue
Block a user