PTP/IEEE1588ハードウェア時刻同期の本番導入｜chronyとの共存設計と精度測定フロー

ハードウェア時刻同期が必要になる場面

NTP や chrony によるソフトウェアタイムスタンプ方式は、OS のスケジューラや割り込み処理に起因するジッタが積み重なり、精度は一般的に数百マイクロ秒〜数ミリ秒にとどまります。多くの用途ではこれで十分ですが、以下のようなシステムでは不足します。

• 金融取引システムの監査ログ（MiFID II や米国 CAT 規制では 100 μs 以内のタイムスタンプ精度が要求されます）
• 5G eCPRI フロントホールの位相同期（ITU-T G.8275.1 では ±1.5 μs 以内が標準要件）
• TiDB・CockroachDB などの分散トランザクション DB（グローバル読取一貫性はクロック精度に依存）
• 放送・映像配信の SMPTE ST 2110 準拠環境

PTP（Precision Time Protocol）は IEEE 1588 として標準化されたプロトコルで、NIC がハードウェアタイムスタンプ機能（PHC: PTP Hardware Clock）を持つ場合、送受信パケットに OS を介さず直接タイムスタンプを付与できます。これにより、適切な機器構成では 100 ナノ秒以下のオーダーでの同期が現実的になります。本記事では Linux 環境における PTP の本番導入手順を、環境確認から切り戻しまで一連のフローとして解説します。

導入前の環境確認：NICとカーネルの対応チェック

NICのハードウェアタイムスタンプ対応確認

PTP のハードウェアタイムスタンプ機能はすべての NIC が持つわけではありません。以下のコマンドで確認します。

ethtool -T eth0

出力の Capabilities に hardware-transmit、hardware-receive、hardware-raw-clock が含まれていれば PTP ハードウェアタイムスタンプが使えます。これらがない場合はソフトウェアタイムスタンプにフォールバックされ、精度が大幅に低下するため PTP 導入の効果が限定的になります。

PHC デバイスの認識も確認します。

ls -l /dev/ptp*

/dev/ptp0 が存在すればカーネルが PHC デバイスとして認識しています。NIC が複数枚あると /dev/ptp1 以降も現れます。

カーネルコンフィグとネットワーク機器の前提

grep CONFIG_PTP /boot/config-$(uname -r)

CONFIG_PTP_1588_CLOCK=y が有効であることを確認します。カーネル 5.4 以降のディストリビューションパッケージでは概ねデフォルトで有効です。また、PTP の精度はソフトウェア設定だけで決まらず、上位の Grandmaster クロック（GPS 受信機や GNSS ベースの時刻機器）の品質と、途中スイッチが Boundary Clock または Transparent Clock に対応しているかどうかにも大きく依存します。通常の L2 スイッチ経由では遅延の非対称性が精度劣化の主因になります。

linuxptpのインストールと基本設定

Linux での PTP 実装には linuxptp パッケージを使います。中心となるデーモンは ptp4l（PTP セッション管理）と phc2sys（PHC とシステムクロックの同期）の 2 つです。

# Debian / Ubuntu
apt install linuxptp

# RHEL 9 / AlmaLinux 9 / Rocky Linux 9
dnf install linuxptp

設定ファイルは Debian 系では /etc/linuxptp/ptp4l.conf、RHEL 系では /etc/ptp4l.conf に置きます。Slave（クライアント）として動作させる最小構成の例です。

[global]
time_stamping           hardware
tx_timestamp_timeout    10
clockClass              135
logging_level           6
summary_interval        0

[eth0]

time_stamping hardware が最も重要なパラメータです。ここを software にするとソフトウェアタイムスタンプに落ちます。[eth0] セクション名は実際の NIC 名（ens3、enp3s0 等）に合わせてください。

ptp4l を有効化します。

systemctl enable --now ptp4l

PHC とシステムクロックを同期させるために phc2sys を起動します。本番環境では systemd サービスとして管理するため、/etc/systemd/system/phc2sys.service を作成します。

[Unit]
Description=PHC to System Clock Sync
After=ptp4l.service
Requires=ptp4l.service

[Service]
ExecStart=/usr/sbin/phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -w -m
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now phc2sys

chronyとの共存設計

PTP 単体で運用すると Grandmaster クロックや上位ネットワークに障害が発生した際に時刻同期が止まります。chrony を NTP フォールバックとして残す構成が一般的で、方法は大きく 2 通りあります。

方法A：PHCをchronyのrefclockとして使う（推奨）

phc2sys を使わず、chrony が直接 PHC を参照してシステムクロックを制御する方法です。/etc/chrony.conf に以下を追加します。

refclock PHC /dev/ptp0 poll 0 dpoll -2 offset 0

この構成では PHC → chrony → システムクロック という経路になります。phc2sys は不要になり、既存の NTP ソースも server ディレクティブでそのまま残せます。PHC が利用可能な間は PHC を優先参照し、異常時は NTP 側へ自動フォールバックします。phc2sys を直接使う場合より若干精度は落ちますが、運用の単純さと可用性のバランスが取りやすく、実運用で選ばれることが多いアプローチです。

方法B：ptp4l＋phc2sysをメインとし、chronyをフォールバックに限定する

phc2sys でシステムクロックを制御しつつ、chrony は NTP ソースのみ参照させる構成です。ただし chrony と phc2sys が同時にシステムクロックを調整しようとすると競合が生じます。chrony 側で makestep の閾値を極端に小さく設定するか、クロック調整を無効化して NTP 差分の監視だけに使うといった対処が必要になります。設定が複雑になるため、特段の理由がなければ方法 A が無難です。

systemd-timesyncdの無効化

Ubuntu 等では systemd-timesyncd がデフォルトで動作しています。chrony や phc2sys と同時に動作するとクロック制御が競合するため、必ず無効化します。

systemctl disable --now systemd-timesyncd
systemctl mask systemd-timesyncd

精度測定と動作検証のフロー

ptp4lログでオフセットを確認する

ptp4l は起動後、定期的にマスターとのオフセットをログ出力します。

journalctl -u ptp4l -f

以下のような行が出力されます。

ptp4l[123.456]: master offset   -23 s2 freq  +2847 path delay  1234

master offset（ナノ秒単位）が安定して ±100 ns 以内に収まっていれば、ハードウェアタイムスタンプが有効に機能しています。起動直後は大きな値を示しますが、PI サーボが収束するにつれて小さくなります。しばらく経っても数マイクロ秒以上の誤差が続く場合は、タイムスタンプモードがソフトウェアに落ちていないか、または上位クロックの品質を確認します。

pmcコマンドでデータセットを取得する

pmc -u -b 0 'GET CURRENT_DATA_SET'

offsetFromMaster と meanPathDelay が返ります。前者がナノ秒単位の現在オフセット、後者がグランドマスターまでの片道遅延推定値です。これらの値を Prometheus の textfile コレクターや node_exporter カスタムメトリクスとして取り込むと、Grafana での継続的な精度監視が容易になります。

chrony経由の場合はchronyc追跡で確認する

chronyc tracking
chronyc sourcestats

chronyc tracking の Reference ID 欄が PHC0 になっていれば PHC を参照中です。System time 行にシステムクロックのオフセット（秒単位）が表示されます。chronyc sourcestats で PHC ソースの標準偏差とオフセット推移も確認できます。

切り戻し手順・よくあるつまずき・2026年の環境差分

切り戻し手順

PTP 同期が期待どおりに機能しない場合や上位 Grandmaster の障害が継続する場合は、以下の手順で NTP 同期に戻します。

systemctl stop phc2sys ptp4l
systemctl unmask systemd-timesyncd
systemctl enable --now systemd-timesyncd
# chrony を NTP 専用に戻す場合は refclock 行をコメントアウトして再起動
systemctl restart chronyd

切り戻し後は chronyc tracking で NTP ソースに切り替わったことを確認します。大きなオフセットが残っている場合は chronyc makestep で強制ステップ補正を実施します。

よくあるつまずき

• インタフェース名の誤り：ptp4l.conf の [eth0] セクション名が実際の NIC 名（ens3、enp6s0f0 等）と一致していないケースが多いです。ip link で確認したうえで設定します。
• タイムスタンプモードの意図しないフォールバック：ethtool -T で hardware-raw-clock が確認できても、ドライバとファームウェアの組み合わせによってはソフトウェアタイムスタンプで動作することがあります。ptp4l ログに selected /dev/ptp0 as PTP clock が出力されているかを確認します。
• VLAN 環境での PTP フレームロスト：一部のスイッチ設定で PTP フレーム（EtherType 0x88F7）が VLAN タグ処理によってドロップされることがあります。
• phc2sys と chrony の競合：両方が同時にシステムクロックを調整すると、クロックが激しく変動します。システムクロックの制御は必ずどちらか一方に委ねる設計にします。

2026年時点の現行環境差分

• Ubuntu 24.04 LTS（Noble Numbat）：systemd-timesyncd がデフォルト有効のため、chrony または linuxptp を導入する際は systemctl mask systemd-timesyncd が必須です。apt install chrony は timesyncd を停止しますが mask までは行わないため、再起動後に復活するケースに注意します。
• RHEL 9 / AlmaLinux 9 / Rocky Linux 9：chronyd がデフォルト有効で systemd-timesyncd は含まれないため、競合の心配はありません。linuxptp 4.x が標準リポジトリに含まれます。
• linuxptp 4.x 系：2024年以降のリリースで設定パラメータ名に一部変更があります。ptp4l --version でバージョンを確認し、ディストリビューションのデフォルト設定ファイルを出発点にするのが安全です。
• Intel i225 / i226 NIC：2.5 GbE カードとして広く普及していますが、ファームウェアバージョンによって PTP 精度に差があります。linuxptp 3.1.1 以降との組み合わせで安定動作が確認されており、古いファームウェアのままにしないことが推奨されます。
• systemd 255 以降：systemd-timesyncd が PHC を直接参照できる実験的機能が追加されましたが、2026年10月時点では本番利用は限定的です。linuxptp との組み合わせでは引き続き timesyncd のマスクが推奨されます。