16.2. Precision Time Protocol デバイスの設定
PTP Operator は NodePtpDevice.ptp.openshift.io
カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。
PTP Operator は、インストールされている場合、クラスター内の各ノードで Precision Time Protocol (PTP) 対応のネットワークデバイスを検索します。この Operator は、互換性のある PTP 対応ネットワークデバイスを提供する各ノードの NodePtpDevice
カスタムリソース (CR) オブジェクトを作成および更新します。
PTP 機能が組み込まれたネットワークインターフェイスコントローラー (NIC) ハードウェアでは、デバイス固有の設定が必要な場合があります。PtpConfig
カスタムリソース (CR) でプラグインを設定することで、PTP Operator でサポートされているハードウェア固有の NIC 機能を使用できます。linuxptp-daemon
サービスが、plugin
スタンザ内の名前付きパラメーターを使用して、特定のハードウェア設定に基づいて linuxptp
プロセス、ptp4l
および phc2sys
を起動します。
OpenShift Container Platform 4.16 では、Intel E810 NIC が PtpConfig
プラグインでサポートされています。
16.2.1. CLI を使用した PTP Operator のインストール
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
- PTP に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
PTP Operator の namespace を作成します。
次の YAML を
ptp-namespace.yaml
ファイルに保存します。apiVersion: v1 kind: Namespace metadata: name: openshift-ptp annotations: workload.openshift.io/allowed: management labels: name: openshift-ptp openshift.io/cluster-monitoring: "true"
namespace
CR を作成します。$ oc create -f ptp-namespace.yaml
PTP Operator の Operator グループを作成します。
次の YAML を
ptp-operatorgroup.yaml
ファイルに保存します。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ptp-operators namespace: openshift-ptp spec: targetNamespaces: - openshift-ptp
OperatorGroup
CR を作成します。$ oc create -f ptp-operatorgroup.yaml
PTP Operator にサブスクライブします。
次の YAML を
ptp-sub.yaml
ファイルに保存します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ptp-operator-subscription namespace: openshift-ptp spec: channel: "stable" name: ptp-operator source: redhat-operators sourceNamespace: openshift-marketplace
Subscription
CR を作成します。$ oc create -f ptp-sub.yaml
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
$ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase
出力例
Name Phase 4.16.0-202301261535 Succeeded
16.2.2. Web コンソールを使用した PTP Operator のインストール
クラスター管理者は、Web コンソールを使用して PTP Operator をインストールできます。
先のセクションで説明されているように namespace および Operator グループを作成する必要があります。
手順
OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub をクリックします。 - 利用可能な Operator のリストから PTP Operator を選択してから Install をクリックします。
- Install Operator ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Install をクリックします。
-
OpenShift Container Platform Web コンソールで、Operators
オプション: PTP Operator が正常にインストールされていることを確認します。
-
Operators
Installed Operators ページに切り替えます。 PTP Operator が Status が InstallSucceeded の状態で openshift-ptp プロジェクトにリスト表示されていることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
-
Operators
Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。 -
Workloads
Pods ページに移動し、 openshift-ptp
プロジェクトで Pod のログを確認します。
-
Operators
-
Operators
16.2.3. クラスター内の PTP 対応ネットワークデバイスの検出
PTP 対応ネットワークデバイスを設定できるように、クラスター内に存在する PTP 対応ネットワークデバイスを特定します。
前提条件
- PTP Operator がインストールされている。
手順
クラスター内の PTP 対応ネットワークデバイスの一覧を返すには、以下のコマンドを実行します。
$ oc get NodePtpDevice -n openshift-ptp -o yaml
出力例
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 ...
16.2.4. linuxptp サービスをグランドマスタークロックとして設定する
ホスト NIC を設定する PtpConfig
カスタムリソース (CR) を作成することで、linuxptp
サービス (ptp4l
、phc2sys
、ts2phc
) をグランドマスタークロック (T-GM) として設定できます。
ts2phc
ユーティリティーを使用すると、システムクロックを PTP グランドマスタークロックと同期できるため、ノードは高精度クロック信号をダウンストリームの PTP 通常クロックおよび境界クロックにストリーミングできます。
次の PtpConfig
CR の例をベースとして使用して、linuxptp
サービスを Intel Westport Channel E810-XXVDA4T ネットワークインターフェイスの T-GM として設定してください。
PTP 高速イベントを設定するには、ptp4lOpts
、ptp4lConf
、ptpClockThreshold
に適切な値を設定します。ptpClockThreshold
は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
- 実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに Intel E810 Westport Channel NIC がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfig
CR を作成します。以下に例を示します。要件に応じて、デプロイメントに次の T-GM 設定のいずれかを使用します。YAML を
grandmaster-clock-ptp-config.yaml
ファイルに保存します。例16.1 E810 NIC の PTP グランドマスタークロック設定
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: grandmaster namespace: openshift-ptp annotations: {} spec: profile: - name: "grandmaster" ptp4lOpts: "-2 --summary_interval -4" phc2sysOpts: -r -u 0 -m -w -N 8 -R 16 -s $iface_master -n 24 ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" plugins: e810: 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 - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248" reportOutput: true ts2phcOpts: " " ts2phcConf: | [nmea] ts2phc.master 1 [global] use_syslog 0 verbose 1 logging_level 7 ts2phc.pulsewidth 100000000 #cat /dev/GNSS to find available serial port #example value of gnss_serialport is /dev/ttyGNSS_1700_0 ts2phc.nmea_serialport $gnss_serialport [$iface_master] ts2phc.extts_polarity rising ts2phc.extts_correction 0 ptp4lConf: | [$iface_master] masterOnly 1 [$iface_master_1] masterOnly 1 [$iface_master_2] masterOnly 1 [$iface_master_3] masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 6 clockAccuracy 0x27 offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval -4 kernel_leap 1 check_fup_sync 0 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type BC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0x20 recommend: - profile: "grandmaster" priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
注記E810 Westport Channel NIC の場合は、
ts2phc.nmea_serialport
の値を/dev/gnss0
に設定します。以下のコマンドを実行して CR を作成します。
$ oc create -f grandmaster-clock-ptp-config.yaml
検証
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
プロファイルが正しいことを確認します。
PtpConfig
プロファイルで指定したノードに対応するlinuxptp
デーモンのログを検査します。以下のコマンドを実行します。$ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container
出力例
ts2phc[94980.334]: [ts2phc.0.config] nmea delay: 98690975 ns ts2phc[94980.334]: [ts2phc.0.config] ens3f0 extts index 0 at 1676577329.999999999 corr 0 src 1676577330.901342528 diff -1 ts2phc[94980.334]: [ts2phc.0.config] ens3f0 master offset -1 s2 freq -1 ts2phc[94980.441]: [ts2phc.0.config] nmea sentence: GNRMC,195453.00,A,4233.24427,N,07126.64420,W,0.008,,160223,,,A,V phc2sys[94980.450]: [ptp4l.0.config] CLOCK_REALTIME phc offset 943 s2 freq -89604 delay 504 phc2sys[94980.512]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1000 s2 freq -89264 delay 474
16.2.5. linuxptp サービスをデュアル E810 Westport Channel NIC のグランドマスタークロックとして設定する
ホスト NIC を設定する PtpConfig
カスタムリソース (CR) を作成することで、linuxptp
サービス (ptp4l
、phc2sys
、ts2phc
) をデュアル E810 Westport Channel NIC のグランドマスタークロック (T-GM) として設定できます。
分散型 RAN (D-RAN) のユースケースでは、次の方法でデュアル NIC の PTP を設定できます。
- NIC 1 を、Global Navigation Satellite System (GNSS) のタイムソースに同期します。
-
NIC 2 を、NIC 1 によって提供される 1PPS タイミング出力に同期します。この設定は、
PtpConfig
CR の PTP ハードウェアプラグインによって提供します。
デュアル NIC PTP T-GM 構成では、1 つの ptp4l
インスタンスと、各 NIC に 1 つずつ、2 つの ts2phc
インスタンスを報告する 1 つの ts2phc
プロセスを使用します。ホストのシステムクロックは、GNSS タイムソースに接続されている NIC から同期されます。
次の PtpConfig
CR の例をベースとして使用して、linuxptp
サービスをデュアル Intel Westport Channel E810-XXVDA4T ネットワークインターフェイスの T-GM として設定してください。
PTP 高速イベントを設定するには、ptp4lOpts
、ptp4lConf
、ptpClockThreshold
に適切な値を設定します。ptpClockThreshold
は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
- 実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに 2 つの Intel E810 Westport Channel NIC がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfig
CR を作成します。以下に例を示します。次の YAML を
grandmaster-clock-ptp-config-dual-nics.yaml
ファイルに保存します。例16.2 デュアル E810 NIC の PTP グランドマスタークロック設定
# In this example two cards $iface_nic1 and $iface_nic2 are connected via # SMA1 ports by a cable and $iface_nic2 receives 1PPS signals from $iface_nic1 apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: grandmaster namespace: openshift-ptp annotations: {} spec: profile: - name: "grandmaster" ptp4lOpts: "-2 --summary_interval -4" phc2sysOpts: -r -u 0 -m -w -N 8 -R 16 -s $iface_nic1 -n 24 ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" plugins: e810: enableDefaultConfig: false settings: LocalMaxHoldoverOffSet: 1500 LocalHoldoverTimeout: 14400 MaxInSpecOffset: 100 pins: $e810_pins # "$iface_nic1": # "U.FL2": "0 2" # "U.FL1": "0 1" # "SMA2": "0 2" # "SMA1": "2 1" # "$iface_nic2": # "U.FL2": "0 2" # "U.FL1": "0 1" # "SMA2": "0 2" # "SMA1": "1 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 - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248" reportOutput: true ts2phcOpts: " " ts2phcConf: | [nmea] ts2phc.master 1 [global] use_syslog 0 verbose 1 logging_level 7 ts2phc.pulsewidth 100000000 #cat /dev/GNSS to find available serial port #example value of gnss_serialport is /dev/ttyGNSS_1700_0 ts2phc.nmea_serialport $gnss_serialport [$iface_nic1] ts2phc.extts_polarity rising ts2phc.extts_correction 0 [$iface_nic2] ts2phc.master 0 ts2phc.extts_polarity rising #this is a measured value in nanoseconds to compensate for SMA cable delay ts2phc.extts_correction -10 ptp4lConf: | [$iface_nic1] masterOnly 1 [$iface_nic1_1] masterOnly 1 [$iface_nic1_2] masterOnly 1 [$iface_nic1_3] masterOnly 1 [$iface_nic2] masterOnly 1 [$iface_nic2_1] masterOnly 1 [$iface_nic2_2] masterOnly 1 [$iface_nic2_3] masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 6 clockAccuracy 0x27 offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval -4 kernel_leap 1 check_fup_sync 0 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type BC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 1 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0x20 recommend: - profile: "grandmaster" priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
注記E810 Westport Channel NIC の場合は、
ts2phc.nmea_serialport
の値を/dev/gnss0
に設定します。以下のコマンドを実行して CR を作成します。
$ oc create -f grandmaster-clock-ptp-config-dual-nics.yaml
検証
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
プロファイルが正しいことを確認します。
PtpConfig
プロファイルで指定したノードに対応するlinuxptp
デーモンのログを検査します。以下のコマンドを実行します。$ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container
出力例
ts2phc[509863.660]: [ts2phc.0.config] nmea delay: 347527248 ns ts2phc[509863.660]: [ts2phc.0.config] ens2f0 extts index 0 at 1705516553.000000000 corr 0 src 1705516553.652499081 diff 0 ts2phc[509863.660]: [ts2phc.0.config] ens2f0 master offset 0 s2 freq -0 I0117 18:35:16.000146 1633226 stats.go:57] state updated for ts2phc =s2 I0117 18:35:16.000163 1633226 event.go:417] dpll State s2, gnss State s2, tsphc state s2, gm state s2, ts2phc[1705516516]:[ts2phc.0.config] ens2f0 nmea_status 1 offset 0 s2 GM[1705516516]:[ts2phc.0.config] ens2f0 T-GM-STATUS s2 ts2phc[509863.677]: [ts2phc.0.config] ens7f0 extts index 0 at 1705516553.000000010 corr -10 src 1705516553.652499081 diff 0 ts2phc[509863.677]: [ts2phc.0.config] ens7f0 master offset 0 s2 freq -0 I0117 18:35:16.016597 1633226 stats.go:57] state updated for ts2phc =s2 phc2sys[509863.719]: [ptp4l.0.config] CLOCK_REALTIME phc offset -6 s2 freq +15441 delay 510 phc2sys[509863.782]: [ptp4l.0.config] CLOCK_REALTIME phc offset -7 s2 freq +15438 delay 502
16.2.5.1. グランドマスタークロックの PtpConfig 設定リファレンス
このリファレンスでは、linuxptp
サービス (ptp4l
、phc2sys
、ts2phc
) をグランドマスタークロックとして設定する PtpConfig
カスタムリソース (CR) の設定オプションを説明します。
PtpConfig CR フィールド | 説明 |
---|---|
|
grandmaster クロック動作用に NIC を設定する
プラグインメカニズムにより、PTP Operator は自動ハードウェア設定を行うことができます。Intel Westport Channel NIC の場合、 |
|
|
|
|
| データを破棄する前に、送信者からの送信 (TX) タイムスタンプを待機する最大時間を指定します。 |
| JBOD 境界クロック時間遅延値を指定します。この値は、ネットワーク時間デバイス間で受け渡される時間値を修正するために使用されます。 |
|
注記
ここにリストされているネットワークインターフェイスがグランドマスターとして設定されており、 |
|
|
|
|
|
任意。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
16.2.5.2. グランドマスタークロッククラスの同期状態のリファレンス
次の表は、PTP グランドマスタークロック (T-GM) の gm.ClockClass
の状態を示しています。クロッククラスの状態では、Primary Reference Time Clock (PRTC) またはその他のタイミングソースに関連する精度と安定性に基づいて T-GM クロックが分類されます。
ホールドオーバー仕様とは、PTP クロックがプライマリータイムソースから更新を受信せずに同期を維持できる時間です。
クロッククラスの状態 | 説明 |
---|---|
|
T-GM クロックは |
|
T-GM クロックは |
|
T-GM クロックは |
|
T-GM クロックは |
詳細は、"Phase/time traceability information", ITU-T G.8275.1/Y.1369.1 Recommendations を参照してください。
16.2.5.3. Intel Westport Channel E810 ハードウェア設定リファレンス
ここでは、Intel E810-XXVDA4T ハードウェアプラグイン を使用して E810 ネットワークインターフェイスを PTP グランドマスタークロックとして設定する方法を説明します。ハードウェアピンの設定により、ネットワークインターフェイスがシステム内の他のコンポーネントやデバイスとどのようにやり取りするかが決まります。E810-XXVDA4T NIC には、外部 1PPS 信号用の 4 つのコネクター (SMA1
、SMA2
、U.FL1
、および U.FL2)
があります。
ハードウェアピン | 推奨設定 | 説明 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
SMA1
コネクターと U.FL1
コネクターはチャネル 1 を共有します。SMA2
コネクターと U.FL2
コネクターはチャネル 2 を共有します。
PtpConfig
カスタムリソース (CR) で GNSS クロックを設定するには、spec.profile.plugins.e810.ublxCmds
パラメーターを設定します。これらの ublxCmds
スタンザはそれぞれ、ubxtool
コマンドを使用してホスト NIC に適用する設定と対応しています。以下に例を示します。
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
次の表は、同等の ubxtool
コマンドを示しています。
ubxtool コマンド | 説明 |
---|---|
|
アンテナ電圧制御を有効にします。アンテナのステータスを |
| アンテナが GPS 信号を受信できるようにします。 |
| Galileo GPS 衛星から信号を受信するようにアンテナを設定します。 |
| アンテナが GLONASS GPS 衛星から信号を受信できないようにします。 |
| アンテナが BeiDou GPS 衛星から信号を受信できないようにします。 |
| アンテナが SBAS GPS 衛星から信号を受信できないようにします。 |
| GNSS 受信機のサーベイインプロセスを設定して、初期位置の推定を改善します。最適な結果が得られるまでに最大 24 時間かかる場合があります。 |
| ハードウェアの自動スキャンを 1 回実行し、NIC の状態と構成設定を報告します。 |
E810 プラグインは次のインターフェイスを実装します。
インターフェイス | 説明 |
---|---|
|
|
|
PTP プロセスを起動して |
|
|
E810 プラグインには次の構造体と変数があります。
構造体 | 説明 |
---|---|
| E810 プラグインのオプション (ブール値フラグやネットワークデバイスピンのマップなど) を表します。 |
|
ブール値フラグとコマンド引数の文字列のスライスを使用して、 |
| プラグインの実行中に使用されるプラグイン固有のデータを保持します。 |
16.2.5.4. デュアル E810 Westport Channel NIC 設定リファレンス
ここでは、Intel E810-XXVDA4T ハードウェアプラグイン を使用して、E810 ネットワークインターフェイスのペアを PTP グランドマスタークロック (T-GM) として設定する方法を説明します。
デュアル NIC クラスターホストを設定する前に、1PPS フェイスプレート接続を使用して 2 つの NIC を SMA1 ケーブルで接続する必要があります。
デュアル NIC T-GM を設定する際は、SMA1 接続ポートを使用して NIC を接続する場合に発生する 1PPS 信号遅延を補正する必要があります。ケーブルの長さ、周囲温度、コンポーネントと製作公差などのさまざまな要因が信号遅延に影響を与える可能性があります。遅延を補正するには、信号遅延のオフセットに使用する特定の値を計算する必要があります。
PtpConfig フィールド | 説明 |
---|---|
| PTP Operator E810 ハードウェアプラグインを使用して E810 ハードウェアピンを設定します。
|
|
|
|
複数の NIC のサポートを有効にするには、 |
16.2.6. PTP グランドマスタークロックの動的なうるう秒処理の設定
PTP Operator コンテナーイメージには、リリース時に利用可能な最新の leap-seconds.list
ファイルが含まれています。PTP Operator は、Global Positioning System (GPS) アナウンスを使用してうるう秒ファイルを自動的に更新するように設定できます。
うるう秒情報は、openshift-ptp
namespace の leap-configmap
という名前の自動生成された ConfigMap
リソースに保存されます。PTP Operator は、ts2phc
プロセスがアクセスできる linuxptp-daemon
Pod 内のボリュームとして leap-configmap
リソースをマウントします。
GPS 衛星が新しいうるう秒データをブロードキャストすると、PTP Operator は leap-configmap
リソースを新しいデータで更新します。ts2phc
プロセスは変更を自動的に取得します。
次の手順は参考用です。PTP Operator のバージョン 4.16 では、デフォルトで自動うるう秒管理が有効になります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールし、クラスターに PTP グランドマスタークロック (T-GM) を設定した。
手順
PtpConfig
CR のphc2sysOpts
セクションで自動うるう秒処理を設定します。以下のオプションを設定します。phc2sysOpts: -r -u 0 -m -w -N 8 -R 16 -S 2 -s ens2f0 -n 24 1
- 1
-w
を設定して、ptp4l
によるシステムハードウェアクロックの同期完了を待機してから、phc2sys
に独自の同期プロセスを開始するよう強制します。
注記以前は、過去のうるう秒を考慮するために、
phc2sys
設定 (-O -37
) のオフセット調整が T-GM に必要でした。これは不要になりました。PtpConfig
CR のspec.profile.plugins.e810.ublxCmds
セクションで、GPS レシーバーによるNAV-TIMELS
メッセージの定期的な報告を有効にするように Intel e810 NIC を設定します。以下に例を示します。- args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248"
検証
設定した T-GM が接続先の GPS から
NAV-TIMELS
メッセージを受信していることを確認します。以下のコマンドを実行します。$ oc -n openshift-ptp -c linuxptp-daemon-container exec -it $(oc -n openshift-ptp get pods -o name | grep daemon) -- ubxtool -t -p NAV-TIMELS -P 29.20
出力例
1722509534.4417 UBX-NAV-STATUS: iTOW 384752000 gpsFix 5 flags 0xdd fixStat 0x0 flags2 0x8 ttff 18261, msss 1367642864 1722509534.4419 UBX-NAV-TIMELS: iTOW 384752000 version 0 reserved2 0 0 0 srcOfCurrLs 2 currLs 18 srcOfLsChange 2 lsChange 0 timeToLsEvent 70376866 dateOfLsGpsWn 2441 dateOfLsGpsDn 7 reserved2 0 0 0 valid x3 1722509534.4421 UBX-NAV-CLOCK: iTOW 384752000 clkB 784281 clkD 435 tAcc 3 fAcc 215 1722509535.4477 UBX-NAV-STATUS: iTOW 384753000 gpsFix 5 flags 0xdd fixStat 0x0 flags2 0x8 ttff 18261, msss 1367643864 1722509535.4479 UBX-NAV-CLOCK: iTOW 384753000 clkB 784716 clkD 435 tAcc 3 fAcc 218
leap-configmap
リソースが PTP Operator によって正常に生成され、leap-seconds.list の最新バージョンに更新されていることを確認します。以下のコマンドを実行します。$ oc -n openshift-ptp get configmap leap-configmap -o jsonpath='{.data.<node_name>}' 1
- 1
<node_name>
は、自動うるう秒管理を使用する PTP T-GM クロックをインストールおよび設定したノードに置き換えます。ノード名内の特殊文字をエスケープします。たとえば、node-1\.example\.com
とします。
出力例
# Do not edit # This file is generated automatically by linuxptp-daemon #$ 3913697179 #@ 4291747200 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 2303683200 12 # 1 Jan 1973 2335219200 13 # 1 Jan 1974 2366755200 14 # 1 Jan 1975 2398291200 15 # 1 Jan 1976 2429913600 16 # 1 Jan 1977 2461449600 17 # 1 Jan 1978 2492985600 18 # 1 Jan 1979 2524521600 19 # 1 Jan 1980 2571782400 20 # 1 Jul 1981 2603318400 21 # 1 Jul 1982 2634854400 22 # 1 Jul 1983 2698012800 23 # 1 Jul 1985 2776982400 24 # 1 Jan 1988 2840140800 25 # 1 Jan 1990 2871676800 26 # 1 Jan 1991 2918937600 27 # 1 Jul 1992 2950473600 28 # 1 Jul 1993 2982009600 29 # 1 Jul 1994 3029443200 30 # 1 Jan 1996 3076704000 31 # 1 Jul 1997 3124137600 32 # 1 Jan 1999 3345062400 33 # 1 Jan 2006 3439756800 34 # 1 Jan 2009 3550089600 35 # 1 Jul 2012 3644697600 36 # 1 Jul 2015 3692217600 37 # 1 Jan 2017 #h e65754d4 8f39962b aa854a61 661ef546 d2af0bfa
16.2.7. linuxptp サービスを境界クロックとして設定
PtpConfig
カスタムリソース (CR) オブジェクトを作成して、linuxptp
サービス (ptp4l
、phc2sys
を設定できます。
次の例の PtpConfig
CR を、特定のハードウェアおよび環境の境界クロックとして linuxptp
サービスを設定する基礎として使用します。この例の CR は PTP 高速イベントを設定しません。PTP 高速イベントを設定するには、ptp4lOpts
、ptp4lConf
、ptpClockThreshold
に適切な値を設定します。ptpClockThreshold
は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
以下の
PtpConfig
CR を作成してから、YAML をboundary-clock-ptp-config.yaml
ファイルに保存します。PTP 境界クロックの設定例
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock namespace: openshift-ptp annotations: {} spec: profile: - name: boundary-clock ptp4lOpts: "-2" phc2sysOpts: "-a -r -n 24" ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" ptp4lConf: | # The interface name is hardware-specific [$iface_slave] masterOnly 0 [$iface_master_1] masterOnly 1 [$iface_master_2] masterOnly 1 [$iface_master_3] masterOnly 1 [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 G.8275.x 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 50 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 clock_class_threshold 135 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 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 BC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 recommend: - profile: boundary-clock priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
表16.8 PTP 境界クロックの CR 設定オプション CR フィールド 説明 name
PtpConfig
CR の名前。profile
1 つ以上の
profile
オブジェクトの配列を指定します。name
プロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。
ptp4lOpts
ptp4l
サービスのシステム設定オプションを指定します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名-i <interface>
およびサービス設定ファイル-f /etc/ptp4l.conf
を含めないでください。ptp4lConf
ptp4l
を境界クロックとして起動するために必要な設定を指定します。たとえば、ens1f0
はグランドマスタークロックから同期し、ens1f3
は接続されたデバイスを同期します。<interface_1>
同期クロックを受信するインターフェイス。
<interface_2>
synchronization クロックを送信するインターフェイス。
tx_timestamp_timeout
Intel Columbiaville 800 Series NIC の場合、
tx_timestamp_timeout
を50
に設定します。boundary_clock_jbod
Intel Columbiaville 800 Series NIC の場合、
boundary_clock_jbod
が0
に設定されていることを確認します。Intel Fortville X710 シリーズ NIC の場合、boundary_clock_jbod
が1
に設定されていることを確認します。phc2sysOpts
phc2sys
サービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator はphc2sys
サービスを開始しません。ptpSchedulingPolicy
ptp4l と phc2sys プロセスのスケジューリングポリシー。デフォルト値は
SCHED_OTHER
です。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO
を使用してください。ptpSchedulingPriority
ptpSchedulingPolicy
がSCHED_FIFO
に設定されている場合に、ptp4l
およびphc2sys
プロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。ptpSchedulingPriority
フィールドは、ptpSchedulingPolicy
がSCHED_OTHER
に設定されている場合は使用されません。ptpClockThreshold
任意。
ptpClockThreshold
が存在しない場合、ptpClockThreshold
フィールドにはデフォルト値が使用されます。ptpClockThreshold
は、PTP マスタークロックが切断されてから PTP イベントが発生するまでの時間を設定します。holdOverTimeout
は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUN
に変わるまでの時間値 (秒単位) です。maxOffsetThreshold
およびminOffsetThreshold
設定は、CLOCK_REALTIME
(phc2sys
) またはマスターオフセット (ptp4l
) の値と比較するナノ秒単位のオフセット値を設定します。ptp4l
またはphc2sys
のオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUN
に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKED
に設定されます。recommend
profile
がノードに適用される方法を定義する 1 つ以上のrecommend
オブジェクトの配列を指定します。.recommend.profile
profile
セクションで定義される.recommend.profile
オブジェクト名を指定します。.recommend.priority
0
から99
までの整数値でpriority
を指定します。数値が大きいほど優先度が低くなるため、99
の優先度は10
よりも低くなります。ノードがmatch
フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。.recommend.match
.recommend.match
ルールをnodeLabel
またはnodeName
の値に指定します。.recommend.match.nodeLabel
oc get nodes --show-labels
コマンドを使用して、ノードオブジェクトのnode.Labels
フィールドのkey
でnodeLabel
を設定します。例:node-role.kubernetes.io/worker
。.recommend.match.nodeName
oc get nodes
コマンドを使用して、nodeName
をノードオブジェクトのnode.Name
フィールドの値に設定します。compute-1.example.com
はその例です。以下のコマンドを実行して CR を作成します。
$ oc create -f boundary-clock-ptp-config.yaml
検証
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
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
プロファイルが正しいことを確認します。
PtpConfig
プロファイルで指定したノードに対応するlinuxptp
デーモンのログを検査します。以下のコマンドを実行します。$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
出力例
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: I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24 I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
16.2.7.1. linuxptp サービスをデュアル NIC ハードウェアの境界クロックとして設定
NIC ごとに PtpConfig
カスタムリソース (CR) オブジェクトを作成することにより、linuxptp
サービス (ptp4l
、phc2sys
) をデュアル NIC ハードウェアの境界クロックとして設定できます。
デュアル NIC ハードウェアを使用すると、各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l
インスタンスをダウンストリームクロックに供給することができます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
「linuxptp サービスを境界クロックとして設定」の参照 CR を各 CR の基礎として使用して、NIC ごとに 1 つずつ、2 つの個別の
PtpConfig
CR を作成します。以下に例を示します。phc2sysOpts
の値を指定して、boundary-clock-ptp-config-nic1.yaml
を作成します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock-ptp-config-nic1 namespace: openshift-ptp spec: profile: - name: "profile1" ptp4lOpts: "-2 --summary_interval -4" ptp4lConf: | 1 [ens5f1] masterOnly 1 [ens5f0] masterOnly 0 ... phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 2
boundary-clock-ptp-config-nic2.yaml
を作成し、phc2sysOpts
フィールドを完全に削除して、2 番目の NIC のphc2sys
サービスを無効にします。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock-ptp-config-nic2 namespace: openshift-ptp spec: profile: - name: "profile2" ptp4lOpts: "-2 --summary_interval -4" ptp4lConf: | 1 [ens7f1] masterOnly 1 [ens7f0] masterOnly 0 ...
- 1
- 2 番目の NIC の境界クロックとして
ptp4l
を開始するために必要なインターフェイスを指定します。
注記2 番目の NIC で
phc2sys
サービスを無効にするには、2 番目のPtpConfig
CR からphc2sysOpts
フィールドを完全に削除する必要があります。
次のコマンドを実行して、デュアル NIC
PtpConfig
CR を作成します。1 番目の NIC の PTP を設定する CR を作成します。
$ oc create -f boundary-clock-ptp-config-nic1.yaml
2 番目の NIC の PTP を設定する CR を作成します。
$ oc create -f boundary-clock-ptp-config-nic2.yaml
検証
PTP Operator が両方の NIC に
PtpConfigCR
を適用していることを確認してください。デュアル NIC ハードウェアがインストールされているノードに対応するlinuxptp
デーモンのログを調べます。たとえば、以下のコマンドを実行します。$ oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container
出力例
ptp4l[80828.335]: [ptp4l.1.config] master offset 5 s2 freq -5727 path delay 519 ptp4l[80828.343]: [ptp4l.0.config] master offset -5 s2 freq -10607 path delay 533 phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1 s2 freq -87239 delay 539
16.2.7.2. デュアル NIC Intel E810 PTP 境界クロック用の高可用性システムクロックとして linuxptp を設定する
linuxptp
サービス ptp4l
および phc2sys
を、デュアル PTP 境界クロック (T-BC) の高可用性 (HA) システムクロックとして設定できます。
高可用性システムクロックは、2 つの境界クロックとして設定されたデュアル NIC Intel E810 Salem チャネルハードウェアからの複数のタイムソースを使用します。2 つの境界クロックインスタンスが HA セットアップに参加し、それぞれ独自の設定プロファイルを持ちます。各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l
インスタンスをダウンストリームクロックに供給します。
NIC を T-BC として設定する 2 つの PtpConfig
カスタムリソース (CR) オブジェクトと、2 つの NIC 間の高可用性を設定する 3 番目の PtpConfig
CR を作成します。
HA を設定する PtpConfig
CR で phc2SysOpts
オプションを 1 回設定します。2 つの NIC を設定する PtpConfig
CR で phc2sysOpts
フィールドを空の文字列に設定します。これにより、2 つのプロファイルに対して個別の phc2sys
プロセスがセットアップされなくなります。
3 番目の PtpConfig
CR は、高可用性システムクロックサービスを設定します。CR は、ptp4l
プロセスが実行されないように、ptp4lOpts
フィールドを空の文字列に設定します。CR は、spec.profile.ptpSettings.haProfiles
キーの下に ptp4l
設定のプロファイルを追加し、それらのプロファイルのカーネルソケットパスを phc2sys
サービスに渡します。ptp4l
障害が発生すると、phc2sys
サービスはバックアップ ptp4l
設定に切り替わります。プライマリープロファイルが再びアクティブになると、phc2sys
サービスは元の状態に戻ります。
HA を設定するために使用する 3 つの PtpConfig
CR すべてに対して、spec.recommend.priority
を同じ値に設定していることを確認します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
- Intel E810 Salem チャネルデュアル NIC を使用してクラスターノードを設定します。
手順
「linuxptp サービスをデュアル NIC ハードウェアの境界クロックとして設定」の CR を各 CR の参照として使用して、NIC ごとに 1 つずつ、2 つの個別の
PtpConfig
CR を作成します。phc2sysOpts
フィールドに空の文字列を指定して、ha-ptp-config-nic1.yaml
ファイルを作成します。以下に例を示します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: ha-ptp-config-nic1 namespace: openshift-ptp spec: profile: - name: "ha-ptp-config-profile1" ptp4lOpts: "-2 --summary_interval -4" ptp4lConf: | 1 [ens5f1] masterOnly 1 [ens5f0] masterOnly 0 #... phc2sysOpts: "" 2
次のコマンドを実行して、NIC 1 に
PtpConfig
CR を適用します。$ oc create -f ha-ptp-config-nic1.yaml
phc2sysOpts
フィールドに空の文字列を指定して、ha-ptp-config-nic2.yaml
ファイルを作成します。以下に例を示します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: ha-ptp-config-nic2 namespace: openshift-ptp spec: profile: - name: "ha-ptp-config-profile2" ptp4lOpts: "-2 --summary_interval -4" ptp4lConf: | [ens7f1] masterOnly 1 [ens7f0] masterOnly 0 #... phc2sysOpts: ""
次のコマンドを実行して、NIC 2 に
PtpConfig
CR を適用します。$ oc create -f ha-ptp-config-nic2.yaml
HA システムクロックを設定する
PtpConfig
CR を作成します。以下に例を示します。ptp-config-for-ha.yaml
ファイルを作成します。2 つの NIC を設定するPtpConfig
CR で設定されているmetadata.name
フィールドと一致するようにhaProfiles
を設定します。例:haProfiles: ha-ptp-config-nic1,ha-ptp-config-nic2
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-ha namespace: openshift-ptp annotations: {} spec: profile: - name: "boundary-ha" ptp4lOpts: "" 1 phc2sysOpts: "-a -r -n 24" ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" haProfiles: "$profile1,$profile2" recommend: - profile: "boundary-ha" priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
- 1
ptp4lOpts
フィールドを空の文字列に設定します。空でない場合、p4ptl
プロセスは重大なエラーで開始されます。
重要個々の NIC を設定する
PtpConfig
CR の前に、高可用性PtpConfig
CR を適用しないでください。次のコマンドを実行して、HA
PtpConfig
CR を適用します。$ oc create -f ptp-config-for-ha.yaml
検証
PTP Operator が
PtpConfig
CR を正しく適用したことを確認します。以下の手順を実行します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkrb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com ptp-operator-657bbq64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
注記linuxptp-daemon
Pod は 1 つだけ存在する必要があります。次のコマンドを実行して、プロファイルが正しいことを確認します。
PtpConfig
プロファイルで指定したノードに対応するlinuxptp
デーモンのログを検査します。$ oc logs linuxptp-daemon-4xkrb -n openshift-ptp -c linuxptp-daemon-container
出力例
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: ha-ptp-config-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.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24 I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
16.2.8. linuxptp サービスを通常のクロックとして設定
PtpConfig
カスタムリソース (CR) オブジェクトを作成して、linuxptp
サービス (ptp4l
、phc2sys
) を通常のクロックとして設定できます。
次の例の PtpConfig
CR を、特定のハードウェアおよび環境の通常クロックとして linuxptp
サービスを設定する基礎として使用します。この例の CR は PTP 高速イベントを設定しません。PTP 高速イベントを設定するには、ptp4lOpts
、ptp4lConf
、ptpClockThreshold
に適切な値を設定します。ptpClockThreshold
は、イベントが有効な場合にのみ必要です。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
以下の
PtpConfig
CR を作成してから、YAML をordinary-clock-ptp-config.yaml
ファイルに保存します。PTP 通常クロックの設定例
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: ordinary-clock namespace: openshift-ptp annotations: {} spec: profile: - name: ordinary-clock # The interface name is hardware-specific interface: $interface ptp4lOpts: "-2 -s" phc2sysOpts: "-a -r -n 24" ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" ptp4lConf: | [global] # # Default Data Set # twoStepFlag 1 slaveOnly 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 255 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval -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 50 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 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 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 L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 recommend: - profile: ordinary-clock priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
表16.9 PTP 通常クロック CR 設定のオプション CR フィールド 説明 name
PtpConfig
CR の名前。profile
1 つ以上の
profile
オブジェクトの配列を指定します。各プロファイルの名前は一意である必要があります。interface
ptp4l
サービスで使用するネットワークインターフェイスを指定します (例:ens787f1
)。ptp4lOpts
ptp4l
サービスのシステム設定オプションを指定します。たとえば、-2
で IEEE 802.3 ネットワークトランスポートを選択します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名-i <interface>
およびサービス設定ファイル-f /etc/ptp4l.conf
を含めないでください。このインターフェイスで PTP 高速イベントを使用するには、--summary_interval -4
を追加します。phc2sysOpts
phc2sys
サービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator はphc2sys
サービスを開始しません。Intel Columbiaville 800 Series NIC の場合、phc2sysOpts
オプションを-a -r -m -n 24 -N 8 -R 16
に設定します。-m
はメッセージをstdout
に出力します。linuxptp-daemon
DaemonSet
はログを解析し、Prometheus メトリックを生成します。ptp4lConf
デフォルトの
/etc/ptp4l.conf
ファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。tx_timestamp_timeout
Intel Columbiaville 800 Series NIC の場合、
tx_timestamp_timeout
を50
に設定します。boundary_clock_jbod
Intel Columbiaville 800 Series NIC の場合、
boundary_clock_jbod
を0
に設定します。ptpSchedulingPolicy
ptp4l
とphc2sys
プロセスのスケジューリングポリシー。デフォルト値はSCHED_OTHER
です。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO
を使用してください。ptpSchedulingPriority
ptpSchedulingPolicy
がSCHED_FIFO
に設定されている場合に、ptp4l
およびphc2sys
プロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。ptpSchedulingPriority
フィールドは、ptpSchedulingPolicy
がSCHED_OTHER
に設定されている場合は使用されません。ptpClockThreshold
任意。
ptpClockThreshold
が存在しない場合、ptpClockThreshold
フィールドにはデフォルト値が使用されます。ptpClockThreshold
は、PTP マスタークロックが切断されてから PTP イベントが発生するまでの時間を設定します。holdOverTimeout
は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUN
に変わるまでの時間値 (秒単位) です。maxOffsetThreshold
およびminOffsetThreshold
設定は、CLOCK_REALTIME
(phc2sys
) またはマスターオフセット (ptp4l
) の値と比較するナノ秒単位のオフセット値を設定します。ptp4l
またはphc2sys
のオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUN
に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKED
に設定されます。recommend
profile
がノードに適用される方法を定義する 1 つ以上のrecommend
オブジェクトの配列を指定します。.recommend.profile
profile
セクションで定義される.recommend.profile
オブジェクト名を指定します。.recommend.priority
通常クロックの
.recommend.priority
を0
に設定します。.recommend.match
.recommend.match
ルールをnodeLabel
またはnodeName
の値に指定します。.recommend.match.nodeLabel
oc get nodes --show-labels
コマンドを使用して、ノードオブジェクトのnode.Labels
フィールドのkey
でnodeLabel
を設定します。例:node-role.kubernetes.io/worker
。.recommend.match.nodeName
oc get nodes
コマンドを使用して、nodeName
をノードオブジェクトのnode.Name
フィールドの値に設定します。compute-1.example.com
はその例です。次のコマンドを実行して、
PtpConfig
CR を作成します。$ oc create -f ordinary-clock-ptp-config.yaml
検証
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
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
プロファイルが正しいことを確認します。
PtpConfig
プロファイルで指定したノードに対応するlinuxptp
デーモンのログを検査します。以下のコマンドを実行します。$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
出力例
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 I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24 I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
16.2.8.1. PTP の通常クロックリファレンスとしての Intel Columbiaville E800 シリーズ NIC
次の表は、Intel Columbiaville E800 シリーズ NIC を通常のクロックとして使用するために、PTP リファレンス設定に加える必要がある変更を説明します。クラスターに適用する PtpConfig
カスタムリソース (CR) に変更を加えます。
PTP 設定 | 推奨設定 |
---|---|
|
|
|
|
|
|
phc2sysOpts
の場合、-m
はメッセージを stdout
に出力します。linuxptp-daemon
DaemonSet
はログを解析し、Prometheus メトリックを生成します。
関連情報
-
PTP 高速イベントを使用して
linuxptp
サービスを通常のクロックとして設定する CR の詳細な例は、linuxptp サービスを通常のクロックとして設定する を参照してください。
16.2.9. PTP ハードウェアの FIFO 優先スケジューリングの設定
低遅延のパフォーマンスを確保する必要のある通信業者などのデプロイメントタイプでは、PTP デーモンスレッドが、残りのインフラストラクチャーコンポーネントとともに、限られた CPU リソースで実行されます。デフォルトでは、PTP スレッドは SCHED_OTHER
ポリシーで実行されます。負荷が高いと、エラーなしで運用する必要のある、これらのスレッドのスケジューリングでレイテンシーが発生する可能性があります。
スケジューリングのレイテンシーでエラーが発生する可能性を軽減するために、SCHED_FIFO
ポリシーでスレッドを実行できるように、PTP Operator の linuxptp
サービスを設定できます。PtpConfig
CR に SCHED_FIFO
が設定されている場合には、ptp4l
と phc2sys
は、PtpConfig
CR の ptpSchedulingPriority
フィールドで設定された優先順位で、chrt
の下の親コンテナーで実行されます。
ptpScheduling Policy
の設定はオプションで、レイテンシーエラーが発生している場合にのみ必要となります。
手順
PtpConfig
CR プロファイルを編集します。$ oc edit PtpConfig -n openshift-ptp
ptpSchedulingPolicy
とptpSchedulingPriority
フィールドを変更します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: <ptp_config_name> namespace: openshift-ptp ... spec: profile: - name: "profile1" ... ptpSchedulingPolicy: SCHED_FIFO 1 ptpSchedulingPriority: 10 2
-
保存して終了すると、
PtpConfig
CR に変更が適用されます。
検証
PtpConfig
CR が適用されたlinuxptp-daemon
Pod と対応するノードの名前を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.com
ptp4l
プロセスが、更新されたchrt
FIFO 優先度で実行されていることを確認します。$ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt
出力例
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
16.2.10. linuxptp サービスのログフィルタリングの設定
linuxptp
デーモンは、デバッグに使用できるログを生成します。ストレージ容量が制限されている通信業者などのデプロイメントタイプでは、これらのログによりストレージ需要が増大する可能性があります。
ログメッセージの数を減らすために、PtpConfig
カスタムリソース (CR) を設定して、master offset
値をレポートするログメッセージを除外できます。master offset
ログメッセージは、現在のノードのクロックとマスタークロックの違いをナノ秒単位でレポートします。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfig
CR を編集します。$ oc edit PtpConfig -n openshift-ptp
spec.profile
で、ptpSettings.logReduce
仕様を追加し、値をtrue
に設定します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: <ptp_config_name> namespace: openshift-ptp ... spec: profile: - name: "profile1" ... ptpSettings: logReduce: "true"
注記デバッグの目的で、この仕様を
False
に戻すと、マスターオフセットメッセージを含めることができます。-
保存して終了すると、
PtpConfig
CR に変更が適用されます。
検証
PtpConfig
CR が適用されたlinuxptp-daemon
Pod と対応するノードの名前を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.com
次のコマンドを実行して、マスターオフセットメッセージがログから除外されていることを確認します。
$ oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset" 1
- 1
- <linux_daemon_container> は、
linuxptp-daemon
Pod の名前です (例:linuxptp-daemon-gmv2n
)。
logReduce
仕様を設定する場合、このコマンドはlinuxptp
デーモンのログにmaster offset
のインスタンスを報告しません。
16.2.11. 一般的な PTP Operator の問題のトラブルシューティング
以下の手順を実行して、PTP Operator で典型的な問題のトラブルシューティングを行います。
前提条件
-
OpenShift Container Platform CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP をサポートするホストを使用して、PTP Operator をベアメタルクラスターにインストールします。
手順
Operator およびオペランドが、設定されたノードについてクラスターに正常にデプロイされていることを確認します。
$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
注記PTP 高速イベントバスが有効な場合には、準備できた
linuxptp-daemon
Pod の数は3/3
になります。PTP 高速イベントバスが有効になっていない場合、2/2
が表示されます。サポートされているハードウェアがクラスターにあることを確認します。
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io
出力例
NAME AGE control-plane-0.example.com 10d control-plane-1.example.com 10d compute-0.example.com 10d compute-1.example.com 10d compute-2.example.com 10d
ノードで利用可能な PTP ネットワークインターフェイスを確認します。
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml
ここでは、以下のようになります。
- <node_name>
問い合わせるノードを指定します (例:
compute-0.example.com
)。出力例
apiVersion: ptp.openshift.io/v1 kind: NodePtpDevice metadata: creationTimestamp: "2021-09-14T16:52:33Z" generation: 1 name: compute-0.example.com namespace: openshift-ptp resourceVersion: "177400" uid: 30413db0-4d8d-46da-9bef-737bacd548fd spec: {} status: devices: - name: eno1 - name: eno2 - name: eno3 - name: eno4 - name: enp5s0f0 - name: enp5s0f1
対応するノードの
linuxptp-daemon
Pod にアクセスし、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。以下のコマンドを実行して、
linuxptp-daemon
Pod の名前と、トラブルシューティングに使用するノードを取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
リモートシェルが必要な
linuxptp-daemon
コンテナーへのリモートシェルです。$ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
ここでは、以下のようになります。
- <linux_daemon_container>
-
診断するコンテナーです (例:
linuxptp-daemon-lmvgn
)。
linuxptp-daemon
コンテナーへのリモートシェル接続では、PTP 管理クライアント (pmc
) ツールを使用して、ネットワークインターフェイスを診断します。以下のpmc
コマンドを実行して、PTP デバイスの同期ステータスを確認します (例:ptp4l
)。# pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
ノードがプライマリークロックに正常に同期されたときの出力例
sending: GET PORT_DATA_SET 40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET portIdentity 40a6b7.fffe.166ef0-1 portState SLAVE logMinDelayReqInterval -4 peerMeanPathDelay 0 logAnnounceInterval -3 announceReceiptTimeout 3 logSyncInterval -4 delayMechanism 1 logMinPdelayReqInterval -4 versionNumber 2
GNSS をソースとするグランドマスタークロックの場合は、次のコマンドを実行して、ツリー内 NIC ice ドライバーが正しいことを確認します。
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-74m2g ethtool -i ens7f0
出力例
driver: ice version: 5.14.0-356.bz2232515.el9.x86_64 firmware-version: 4.20 0x8001778b 1.3346.0
GNSS をソースとするグランドマスタークロックの場合は、
linuxptp-daemon
コンテナーが GNSS アンテナから信号を受信していることを確認します。コンテナーが GNSS 信号を受信していない場合、/dev/gnss0
ファイルにデータが入力されません。検証するには、次のコマンドを実行します。$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-jnz6r cat /dev/gnss0
出力例
$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
16.2.12. Intel 800 シリーズ NIC の CGU の DPLL ファームウェアバージョンを取得する
クラスターノードへのデバッグシェルを開き、NIC ハードウェアを照会することで、Intel 800 シリーズ NIC の Clock Generation Unit (CGU) の digital phase-locked loop (DPLL) ファームウェアバージョンを取得できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - クラスターホストに Intel 800 シリーズ NIC がインストールされている。
- PTP をサポートするホストを含むベアメタルクラスターに PTP Operator をインストールしている。
手順
次のコマンドを実行してデバッグ Pod を起動します。
$ oc debug node/<node_name>
ここでは、以下のようになります。
- <node_name>
- Intel 800 シリーズ NIC をインストールしたノードです。
devlink
ツールと、NIC がインストールされているバスおよびデバイス名を使用して、NIC の CGU ファームウェアバージョンを確認します。たとえば、以下のコマンドを実行します。sh-4.4# devlink dev info <bus_name>/<device_name> | grep cgu
ここでは、以下のようになります。
- <bus_name>
-
NIC がインストールされているバスです (例:
pci
)。 - <device_name>
-
NIC デバイス名です (例:
0000:51:00.0
)。
出力例
cgu.id 36 1 fw.cgu 8032.16973825.6021 2
注記ファームウェアバージョンには、先頭のニブルと、バージョン番号の各部分に対する 3 つのオクテットがあります。
16973825
を 2 進数で表すと0001 0000 0011 0000 0000 0000 0001
になります。バイナリー値を使用してファームウェアバージョンをデコードします。以下に例を示します。表16.11 DPLL ファームウェアバージョン バイナリー部分 10 進数値 0001
1
0000 0011
3
0000 0000
0
0000 0001
1
16.2.13. PTP Operator データの収集
oc adm must-gather
コマンドを使用すると、PTP Operator に関連する機能やオブジェクトなど、クラスターに関する情報を収集できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。 - PTP Operator がインストールされている。
手順
must-gather
を使用して PTP Operator データを収集するには、PTP Operatormust-gather
イメージを指定する必要があります。$ oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel8:v4.16