Meta での Precision Time Protocol の導入方法

Meta に Precision Time Protocol (PTP) を実装することで、当社の製品とサービスをナノ秒の精度で駆動するシステムを同期できるようになります。 PTP の前身である Network Time Protocol (NTP) ではミリ秒の精度が提供されていましたが、次のコンピューティングプラットフォーム、メタバース、AI の構築に向けてより高度なシステムに拡張する際には、サーバーが正確な時刻を維持していることを確認する必要があります。できるだけ正確に、正確に。 PTP を導入することで、コミュニケーションや生産性からエンターテインメント、プライバシー、セキュリティに至るまで、タイムゾーンを超えて世界中のすべての人のために、Meta のテクノロジーとプログラムを強化できるようになります。

PTP への道のりは何年もかかりました。サーバーやデータセンター内で時間管理のハードウェアとソフトウェアの両方がどのように動作するかを再考する必要があったからです。

PTP 移行とそれを可能にしたイノベーションに関する技術的な詳細を共有します。

PTP アーキテクチャに入る前に、説明のために、非常に正確なタイミングを実現する簡単な使用例を見てみましょう。

クライアントがデータを書き込んですぐにそれを読み取ろうとする状況を想像してください。大規模な分散システムでは、書き込みと読み取りが異なるバックエンドノードに到達する可能性が高くなります。

最新の更新がまだ適用されていないリモートレプリカに読み取りがアクセスしている場合、ユーザーには自分の書き込みが表示されない可能性があります。

これは少なくとも迷惑ですが、より重要なのは、これが単一サーバーと同様に分散システムとの対話を可能にする線形化可能性の保証に違反していることです。

これを解決する一般的な方法は、異なるレプリカに複数の読み取りを発行し、クォーラムの決定を待つことです。これにより、余分なリソースが消費されるだけでなく、ネットワークの往復遅延が長くなるために読み取りが大幅に遅延します。

バックエンドとレプリカに正確で信頼性の高いタイムスタンプを追加すると、レプリカが読み取りタイムスタンプに追いつくまで待つだけで済みます。

これにより、読み取りが高速化されるだけでなく、大量の計算能力も節約されます。

この設計が機能するための非常に重要な条件は、すべてのクロックが同期していること、またはクロックと時間源の間のオフセットがわかっていることです。ただし、オフセットは、継続的な補正、ドリフト、または単純な温度変化によって変化します。この目的のために、私たちは不確実性の窓 (WOU) の概念を使用します。これにより、オフセットがどこにあるかを高い確率で知ることができます。この特定の例では、読み取りタイムスタンプに WOU を加えた値まで読み取りをブロックする必要があります。

そのためには PTP は実際には必要ないと主張する人もいるでしょう。 NTP は問題なく動作します。まあ、私たちもそう思いました。しかし、最先端の NTP 実装と初期バージョンの PTP を比較した実験では、パフォーマンスにおよそ 100 倍の違いがあることがわかりました。

イベントトレース、キャッシュの無効化、プライバシー侵害検出の改善、メタバースでの遅延補正、AI での同時実行など、追加のユースケースがいくつかあり、その多くはハードウェア容量要件を大幅に軽減します。これにより、私たちは今後何年も忙しくなるでしょう。

同じページに到達したので、PTP をメタスケールでどのように展開したかを見てみましょう。

信頼性と運用性を何度か検討した結果、PTP ラック、ネットワーク、クライアントの 3 つの主要コンポーネントに分割できる設計にたどり着きました。

バックルを締めてください — 深く掘り下げていきます。

これには、クライアントに時間を提供するハードウェアとソフトウェアが格納されています。ラックは複数の重要なコンポーネントで構成されており、それぞれが慎重に選択され、テストされています。

GNSS アンテナは、最も評価されていないコンポーネントの 1 つです。しかし、少なくとも地球上では、ここが時間の起源となる場所です。

私たちはナノ秒の精度を目指して努力しています。また、GNSS 受信機が位置を正確に特定できない場合、時間を計算することはできません。信号対雑音比 (SNR) を強く考慮する必要があります。低品質のアンテナや外空への障害物により、3D 位置の標準偏差誤差が高くなる可能性があります。時間を極めて正確に決定するには、GNSS 受信機はいわゆる時間モードに入る必要があり、これには通常 10m 未満の 3D 誤差が必要です。

開けた空を確保し、しっかりとした固定アンテナを設置することが絶対に不可欠です。美しい景色も楽しめます。

私たちがさまざまなアンテナソリューションをテストしているときに、比較的新しい GNSS-over-fiber テクノロジーに注目しました。欠点はほとんどありません。光ファイバーを介してレーザーから電力を供給されるため電気を通しません。また、信号は増幅器なしで数キロメートル伝送できます。

建物内では、既存の構造化ファイバーと LC パッチパネルを使用できるため、信号の配信が大幅に簡素化されます。さらに、光ファイバーの信号遅延は 1 メートルあたり約 4.9ns と明確に定義されています。唯一残っているのは、レーザー変調と光スプリッターへの直接 RF によってもたらされる遅延であり、これはボックスごとに約 45ns です。

テストを実施することにより、エンドツーエンドのアンテナ遅延は決定的であり (通常は約数百ナノ秒)、Time Appliance 側で簡単に補正できることが確認されました。

Time Appliance はタイミングインフラストラクチャの中心です。データセンターインフラストラクチャの観点から見た時間は、ここから始まります。 2021 年に、新しい Time Appliance を開発した理由と、既存のソリューションでは解決できない理由を説明する記事を公開しました。

しかし、これは主に NTP のコンテキストでのものでした。一方、PTP にはさらに高い要件と厳しい制約が伴います。最も重要なことは、精度と精度を損なうことなく、アプライアンスごとに最大 100 万のクライアントを確実にサポートすることを約束したことです。これを達成するために、私たちは Time Appliance の従来のコンポーネントの多くを批判的に検討し、その信頼性と多様性について真剣に検討しました。

重大なバグや悪意のある攻撃からインフラストラクチャを保護するために、私たちは時間の源であるタイムカードから多様化を開始することにしました。前回は、タイムカードの設計と FPGA ベースのソリューションの利点について詳しくお話しました。 Open Compute Project (OCP) の下で、当社は Orolia、Meinberg、Nvidia、Intel、Broadcom、ADVA などのベンダーと協力しており、いずれも OCP 仕様に準拠した独自のタイムカードを実装しています。

タイムカードは、特別な構成と監視を必要とする重要なコンポーネントです。この目的のために、私たちは Orolia と協力して、さまざまな種類のタイムカードに対応する oscillatord と呼ばれる規律ソフトウェアを開発しました。これは、以下のデフォルトのツールになりました。

事実上、oscillatord からエクスポートされたデータにより、Time Appliance がトラフィックを受け入れるか排出するかを決定できるようになります。

私たちの最終的な目標は、PTP などのプロトコルをパケットネットワーク上に伝播させることです。タイムカードが Time Appliance の心臓部であるとすれば、ネットワークカードは顔です。時間に敏感なすべての PTP パケットには、NIC によってハードウェアタイムスタンプが付けられます。これは、NIC の PTP ハードウェアクロック (PHC) が正確に制御される必要があることを意味します。

phc2sys または同様のツールを使用して、タイムカードから NIC にクロック値をコピーするだけでは、精度は十分ではありません。実際、私たちの実験では、PCIe、CPU、NUMA などを経由する際に、簡単に約 1 ～ 2 マイクロ秒が失われることが示されています。PCIe バスを介した同期のパフォーマンスは、新たな高精度時間測定 (PTM) テクノロジによって劇的に向上します。この機能を備えたさまざまな周辺機器の開発とサポートが進行中です。

このアプリケーションでは、PPS 入力機能を備えた NIC を使用しているため、最初にクロック値をコピーし、次にパルス/秒 (PPS) 信号に基づいてクロックエッジを調整する ts2phc を採用しました。これには、以下の図に示すように、タイムカードの PPS 出力と NIC の PPS 入力の間に追加のケーブルが必要です。

オフセットを常に監視し、タイムカードと NIC の間の ±50ns の範囲から外れないことを確認します。

また、フェイルセーフとして機能するために NIC の PPS 出力インターフェイスも監視し、NIC 上の PHC で何が起こっているかを実際に把握していることを確認します。

さまざまな既存の PTP サーバー実装を評価しているときに、評価した FPGA アクセラレーション PTP サーバーを含む、オープンソースとクローズドの独自ソリューションの両方でスケーラビリティの問題が発生しました。最大でも、サーバーごとに約 50,000 のクライアントを取得できます。私たちの規模では、これらのデバイスを満載した多くのラックを展開する必要があることを意味します。

PTP の秘密のソースはハードウェアタイムスタンプの使用であるため、サーバー実装は高度に最適化された C プログラムである必要はなく、FPGA アクセラレーションアプライアンスである必要もありません。

私たちは、ptp4u という名前のスケーラブルな PTPv2 ユニキャスト PTP サーバーを Go に実装し、GitHub でオープンソース化しました。いくつかの小規模な最適化により、デバイスあたり 100 万を超える同時クライアントをサポートすることができました。これは、IEEE 1588v2 認定デバイスによって独立して検証されました。

これは、複数の強力なワーカー間でサブスクリプションを渡すことを可能にする、Go のチャネルのシンプルかつエレガントな使用によって可能になりました。

ptp4u は Linux マシン上のプロセスとして実行されるため、IPv6 サポート、ファイアウォールなどのすべての利点を自動的に無料で得ることができます。

ptp4u サーバーには多くの構成オプションがあり、次のような動的に変化するパラメータを渡すことができます。PTP クロックの精度、PTPクロッククラス、そしてUTC オフセット— これは現在 37 秒に設定されています (これが一定になることを期待しています) — クライアントまで。

これらのパラメータを頻繁に生成するために、c4u と呼ばれる別のサービスを実装しました。これは、複数の情報ソースを常に監視し、ptp4u のアクティブな設定をコンパイルします。

これにより、環境が変化した場合の柔軟性と対応力が得られます。たとえば、Time Appliance の 1 つで GNSS 信号が失われた場合、ClockClass を HOLDOVER に切り替え、クライアントはすぐにそこから移行します。また、ts2phc 同期品質、原子時計ステータスなど、さまざまなソースから ClockAccuracy を計算します。

国際原子時 (TAI) をクライアントに渡すため、tzdata パッケージの内容に基づいて UTC オフセット値を計算します。

私たちは、Time Appliance が確立された認定された監視デバイスによって常に独立して評価されるようにしたいと考えていました。幸いなことに、私たちは Calnex とともに NTP 分野ですでに多くの進歩を遂げており、同様のアプローチを PTP にも適用できる立場にありました。

私たちは Calnex と協力して、そのフィールドデバイスをデータセンター用に再利用しました。これには、物理フォームファクターの変更と IPv6 などの機能のサポートの追加が含まれていました。

Time Appliance NIC PPS 出力を Calnex Sentinel に接続すると、NIC の PHC をナノ秒の精度で監視できるようになります。

以下の「PTP アーキテクチャを監視する方法」で監視について詳しく説明します。

PTP プロトコルは、PTP メッセージの送信にユニキャストモードとマルチキャストモードの両方の使用をサポートします。大規模なデータセンターの展開では、ネットワーク設計とソフトウェア要件が大幅に簡素化されるため、マルチキャストよりもユニキャストが推奨されます。

典型的な PTP ユニキャストフローを見てみましょう。

クライアントはネゴシエーションを開始します（ユニキャスト送信を要求します）。したがって、以下を送信する必要があります。

概略的に (説明のために)、次のようになります。

私たちは当初、設計に境界クロックを活用することを検討していました。ただし、境界クロックにはいくつかの欠点と複雑さが伴います。

このさらなる複雑さを回避するために、PTP 透過クロックのみに依存することにしました。

トランスペアレントクロック (TC) を使用すると、クライアントはネットワーク遅延の変動を考慮できるようになり、クロックオフセットのより正確な推定が保証されます。クライアントとタイムサーバー間のパスにある各データセンタースイッチは、パケットペイロード内のフィールド (適切な名前の修正フィールド (CF)) を更新することによって、各 PTP パケットがスイッチを通過するのに費やした時間を報告します。

PTP クライアント (通常クロックまたは OC とも呼ばれます) は、4 つのタイムスタンプ (T1、T2、T3、および T4) と 2 つの補正フィールド値を使用して、ネットワーク平均パス遅延とタイムサーバー (グランドマスタークロックまたは GM) へのクロックオフセットを計算します。 (CFa および CFb)、以下の図に示すように:

クライアントとサーバー間の途中で無効になったトランスペアレントクロックが 1 つだけある場合の影響を理解するには、ログを調べることができます。

パス遅延が爆発的に増加し、通常の運用では発生しないはずの負の値になることもあります。これはオフセットに劇的な影響を与え、±100 ナノ秒から -400 マイクロ秒 (4000 倍以上の差) に変化します。そして何よりも最悪のことは、平均パス遅延の計算が正しくないため、このオフセットさえも正確ではないということです。

私たちの実験によると、大きなバッファを備えた最新のスイッチではパケットが最大数ミリ秒遅延する可能性があり、その結果、数百マイクロ秒のパス遅延計算エラーが発生します。これによりオフセットスパイクが発生し、グラフにはっきりと表示されます。

結論としては、TC が存在しないデータセンターで PTP を実行すると、ラウンドトリップ時間に予測不能で説明不能な非対称性が生じるということです。そして何よりも最悪なのは、これを検出する簡単な方法がなくなることです。 500 マイクロ秒というと大したことではないように聞こえるかもしれませんが、顧客が WOU が数マイクロ秒であることを期待している場合、これは SLA 違反につながる可能性があります。

受信パケットのタイムスタンプは、Linux カーネルによって数十年にわたってサポートされてきた比較的古い機能です。たとえば、ソフトウェア (カーネル) のタイムスタンプは、NTP デーモンによって長年使用されてきました。タイムスタンプはデフォルトではパケットペイロードに含まれていないため、必要に応じてユーザーアプリケーションによってタイムスタンプを配置する必要があることを理解することが重要です。

ユーザー空間から RX タイムスタンプを読み取るのは比較的簡単な操作です。パケットが到着すると、ネットワークカード (またはカーネル) はこのイベントにタイムスタンプを付け、そのタイムスタンプをソケット制御メッセージに含めます。これは、MSG_ERRQUEUE フラグを設定して recvmsg システムコールを呼び出すことで、パケット自体と簡単に連携できます。

TX ハードウェアタイムスタンプの場合は、もう少し複雑です。 sendto syscall が実行されても、即時のパケットの出発や TX タイムスタンプの生成にはつながりません。この場合、ユーザーはカーネルによってタイムスタンプが正確に設定されるまでソケットをポーリングする必要があります。多くの場合、数ミリ秒待つ必要があるため、当然送信速度が制限されます。

ハードウェアタイムスタンプは、PTP を非常に正確にする秘密のソースです。最新の NIC のほとんどは、ネットワークカードドライバーが対応するセクションに入力するハードウェアタイムスタンプサポートをすでに備えています。

ethtool コマンドを実行すると、サポートを確認するのが非常に簡単です。

ソフトウェア (カーネル) タイムスタンプを使用して PTP を使用することは依然として可能ですが、その品質、精度、精度については強力な保証はありません。

私たちはこの可能性も評価し、ハードウェアのタイムスタンプが利用できない場合にソフトウェアでハードウェアのタイムスタンプを「偽装」するためにカーネルに変更を実装することも検討しました。しかし、非常にビジーなホストでは、ソフトウェアのタイムスタンプの精度が数百マイクロ秒に跳ね上がることが観察されたため、この考えを放棄する必要がありました。

ptp4l は、PTP クライアントと PTP サーバーの両方として機能するオープンソースソフトウェアです。パフォーマンス上の理由から独自の PTP サーバーソリューションを実装する必要がありましたが、クライアントのユースケースでは ptp4l を使用することにしました。

ラボでの最初のテストでは、ptp4l がすぐに優れた同期品質を提供し、ローカルネットワーク内の PHC の時間を数十ナノ秒まで調整できることが明らかになりました。

しかし、セットアップをスケールアップし始めると、いくつかの問題が発生し始めました。

ある特定の例では、オフセットに時折「スパイク」があることに気づき始めました。徹底的に調査した結果、市場で最も人気のある NIC の 1 つにおける基本的なハードウェア制限が特定されました。

これにより、最終的には、正当なタイムスタンプが他のパケットからのタイムスタンプに置き換えられることになりました。しかし、事態をさらに悪化させたのは、NIC ドライバーがあまりにも賢く、誰にも告げずにソケット制御メッセージのハードウェアタイムスタンプセクションにソフトウェアタイムスタンプを配置しようとしたことです。

これは、フリートの大部分に影響を与える基本的なハードウェアの制限であり、修正することは不可能です。

オフセット外れ値フィルターを実装する必要がありました。これにより、PI サーボの動作が変更され、ステートフルになりました。その結果、時折の外れ値が破棄され、マイクロホールドオーバー中に平均頻度が設定されるようになりました。

このフィルターがなければ、ptp4l は PHC 周波数を非常に高く設定し、その結果、数秒間の発振が発生し、そこから生成される不確実性の窓の品質が低下することになります。

BMCA の設計から別の問題が発生しました。このアルゴリズムの目的は、ptp4l.conf で複数の Time Appliance から選択できる場合に、最適な Time Appliance を選択することです。これは、アナウンスメッセージでタイムサーバーによって提供されるいくつかの属性を比較することによって行われます。

この問題は、前述の属性がすべて同じである場合に現れます。 BMCA は Time ApplianceMAC アドレスをタイブレーカーとして使用します。これは、通常の動作条件下では、1 つの Time Server がすべてのクライアントトラフィックを引き付けることを意味します。

これに対処するために、プール全体から Time Appliance の異なるサブグループに異なる PTP クライアントを割り当てる、いわゆる「シャーディング」を導入しました。

これは、各サブグループ内の 1 台のサーバーがそのグループの負荷全体を引き受けるという問題を部分的にしか解決しませんでした。解決策は、クライアントが優先順位を表明できるようにすることでした。そのため、MAC アドレスタイブレーカーのすぐ上の選択基準に Priority3 を導入しました。これは、同じ Time Appliance を使用するように構成されたクライアントが異なるサーバーを優先できることを意味します。

クライアント 1:

[ユニキャストマスターテーブル]

UDPv6 タイムサーバー 1 1

UDPv6 タイムサーバー 2 2

UDPv6 タイムサーバー3 3

クライアント 2:

[ユニキャストマスターテーブル]

UDPv6 タイムサーバー 2 1

UDPv6 タイムサーバー3 2

UDPv6 タイムサーバー 1 3

これにより、通常の動作条件下ですべての Time Appliance に負荷を均等に分散できます。

私たちが直面したもう 1 つの大きな課題は、PTP がマルチホスト NIC (複数のホストが同じ物理ネットワークインターフェイス、つまり単一の PHC を共有する) で確実に動作するようにすることでした。ただし、ptp4l はこのことを知らず、他の近隣者がいないかのように PHC を規律しようとします。

一部の NIC メーカーは、ptp4l がカーネルドライバー内の式を制御するだけの、いわゆる「フリーランニング」モードを開発しました。実際の PHC は影響を受けず、引き続き無料で実行されます。このモードでは精度が若干悪くなりますが、ptp4l に対しては完全に透過的です。

他の NIC メーカーは、ロックを取得した最初のホストが実際に PHC を制御する場合の「リアルタイムクロック」モードのみをサポートしています。ここでの利点は、より正確なキャリブレーションと高品質のホールドオーバーですが、PHC 周波数を調整しようとしても影響がないため、同じ NIC を使用する他のホストで実行されている ptp4l に別の問題が発生し、クロックオフセットと周波数の計算が不正確になる可能性があります。

データセンターの構成を説明するために、前述のエッジケースやその他多くのケースを反映した PTP プロファイルを開発して公開しました。

代替の PTP クライアントを使用する可能性を評価中です。私たちの主な基準は次のとおりです。

私たちは Timebeat PTP クライアントを評価していますが、これまでのところ、非常に有望に見えます。

PTP プロトコルでは、UTC オフセットをクライアントに渡す限り、伝播時間を気にする必要はありません。この例では国際原子時 (TAI) ですが、UTC を選択する人もいるかもしれません。私たちは、継続的に増加するカウンターとして提供される時間を考えたいと思います。

この時点ではシステムクロックを制御しておらず、ptp4l は NIC の PHC を制御するためにのみ使用されます。

サーバー群全体で PHC を同期するのは良いことですが、クライアント上でこれらの数値を読み取って操作する方法がなければ意味がありません。

この目的のために、PHC と ptp4l から情報を収集し、理解しやすい不確実性の窓の情報を公開する fb Clock と呼ばれるシンプルで軽量な API を開発しました。

非常に効率的な ioctl PTP_SYS_OFFSET_EXTENDED を通じて、fblock は PHC から現在のタイムスタンプを取得し、ptp4l から最新のデータを取得し、数式を適用して不確実性の窓 (WOU) を計算します。

ご覧のとおり、API は現在時刻 (別名 time.Now()) を返しません。代わりに、非常に高い確率で実際の時間を含む時間ウィンドウを返します。この特定の例では、不確実性ウィンドウが 694 ナノ秒であり、その時間が (TAI) 2022 年 6 月 2 日木曜日 17:44 の間であることがわかります。 08:711023134と2022年6月2日木曜日17:44:08:711023828。

このアプローチにより、顧客は正確なトランザクション順序を確保するために間隔が経過するまで待つことができます。

時間の精度または (不確実性の窓) を測定するということは、配信される時間の値とともに、正確な時間を高いレベルで確実に含むことが保証された窓 (プラス/マイナスの値) が提示されることを意味します。

どの程度確実である必要があるかは、時間が正確であることがどの程度重要であるかによって決まり、これは特定のアプリケーションによって決まります。

私たちの場合、この確実性は 99.9999% (6 ～ 9 秒) よりも優れている必要があります。このレベルの信頼性では、1,000,000 回の測定で誤差が 1 件未満であることが期待できます。

誤り率の推定では、データの履歴 (ヒストグラム) の観察を使用して確率分布関数 (PDF) を当てはめます。確率分布関数から分散を計算でき (二乗根を取り、標準偏差を取得します)、そこから単純な乗算を行って、その値に基づいて分布を推定します。

以下は、通常のクロックで実行されている ptp4l からのオフセット測定から取得したヒストグラムです。

合計分散 (E2E) を推定するには、エンドノード NIC に至るまでのタイムサーバーによって蓄積された時刻誤差の分散を知る必要があります。これには、GNSS、原子時計、タイムカード PHC から NIC PHC (ts2phc) への接続が含まれます。メーカーは GNSS 誤差分散を提供しています。 UBX-F9Tの場合は約12ナノ秒です。原子時計の場合、値は設定した規律しきい値によって異なります。規律しきい値が厳しくなるほど、オフセットの分散は小さくなりますが、ホールドオーバーのパフォーマンスは低くなります。この実験を実行した時点では、原子時計の誤差分散は 43ns (標準偏差、std) と測定されました。最後に、ツール ts2phc は分散を 30ns (標準) 増加させ、合計分散は 52ns になります。

観察された結果は、「分散和の法則」によって計算された分散と一致します。

分散和の法則によれば、必要なのはすべての分散を加算することだけです。私たちの場合、オブザーバー E2E 誤差の合計 (Calnex Sentinel 経由で測定) は約 92ns であることがわかります。

一方、推定では次のことが考えられます。

推定される E2E 分散 = [GNSS 分散 + MAC 分散 + ts2phc 分散] + [PTP4L オフセット分散] = [タイムサーバー分散] + [通常のクロック分散]

値を代入します。

推定 E2E 分散 = (12ns 2) + (43ns2) + (52ns2) + (61ns2) = 8418、91.7ns に相当

これらの結果は、誤差分散をクロックツリーに伝播することにより、E2E 誤差分散を良好な精度で推定できることを示しています。 E2E 誤差分散は、次の表に基づいて不確実性の窓 (WOU) を計算するために使用できます。

単純に、推定された E2E 誤差分散に 4.745 を乗算することで、6 ～ 9 秒の確率の不確実性の窓を推定できます。

与えられたシステムの場合、6 ～ 9 の確率は約 92ns x 4.745 = 436ns です。

これは、PTP によって報告された時間が与えられた場合、値の周囲の 436ns のウィンドウサイズを考慮すると、99.9999% 以上の信頼度で真の時間を含むことが保証されることを意味します。

上記はすべて論理的で素晴らしいように見えますが、そこには大きな前提があります。オープンタイムサーバー (OTS) への接続が利用可能であり、すべてが通常の動作モードであることが前提となります。 OTS がダウンする、スイッチがダウンする、同期メッセージが想定どおりに動作しない、その間の何かがオンコールをウェイクアップすることを決定するなど、多くのことが問題になる可能性があります。そのような状況では、誤差範囲の計算は次のようになります。ホールドオーバーモードに入ります。 GNSS がダウンしている場合、OTS にも同じことが当てはまります。このような状況では、システムは複利率に基づいて不確実性の窓を増加させます。レートは、通常動作中のオシレーターの安定性 (スクロールの変動) に基づいて推定されます。 OTS では、システムの正確な遠隔測定モニタリング (温度、振動など) によって複合レートが調整されます。ここで係数を調整し、最良の結果を得るにはかなりの作業があり、現在も微調整に取り組んでいます。

ネットワーク同期が利用可能な期間中、サーボはクライアント側のローカルクロックの周波数を常に調整しています (最初のステッピングが収束したと仮定します)。ネットワーク同期が中断されると (タイムサーバーへの接続が失われたり、タイムサーバー自体がダウンしたりすることにより)、サーボには最後の周波数補正値が残ります。そのため、このような値はローカルクロックの精度の推定を目的としたものではなく、クラインとタイムサーバー間で測定された時間誤差 (オフセット) を減らすための一時的な周波数調整を目的としています。

したがって、最初に同期喪失期間を考慮し、周波数補正の最良の推定値 (通常は以前の補正値のスクロール平均) を使用し、次に、最後の補正値を調べて比較することで誤差限界の増加を考慮する必要があります。以前の補正値のスクロール平均を使用します。

モニタリングは、PTP アーキテクチャの最も重要な部分の 1 つです。サービスの性質と影響により、私たちはツールの開発にかなりの時間を費やしてきました。

私たちは Calnex チームと協力して Sentinel HTTP API を作成しました。これにより、デバイスからのデータの管理、構成、エクスポートが可能になります。 Meta では、人間とスクリプトに優しい対話を可能にする API コマンドラインツールを作成し、オープンソース化しました。

Calnex Sentinel 2.0 を使用すると、アプライアンスごとに 3 つの主要なメトリクス (NTP、PTP、PPS) を監視できます。

これにより、アプライアンスに関する問題についてエンジニアに通知し、問題の場所を正確に検出できるようになります。

たとえば、この場合、NTP が 8 マイクロ秒以内にとどまる場合、PTP と PPS の両方のモニタリングの変動は 24 時間でおよそ 100 ナノ秒未満になります。

設定を監視するために、ptpcheck というツールを実装し、オープンソース化しました。さまざまなサブコマンドがありますが、最も興味深いものは次のとおりです。

Client サブコマンドは、ptp クライアントの全体的なステータスを提供します。最後の同期メッセージの受信時刻、選択したタイムサーバーへのクロックオフセット、平均パス遅延、およびその他の役立つ情報が報告されます。

fb Clock API のクエリと現在の不確実性ウィンドウの取得を可能にするクライアントサブコマンド:

Chrony スタイルのクライアント監視により、クライアント構成ファイルで構成されたすべてのタイムサーバー、そのステータス、および時間の質を確認できます。

Server サブコマンドを使用すると、タイムカードから概要を読み取ることができます。

たとえば、タイムカードの最後の修正はわずか 1 ナノ秒であったことがわかります。

このサブコマンドを使用すると、任意の 2 つの PHC 間の違いを取得できます。

この特定のケースでは、タイムカードとサーバー上の NIC の差は -15 ナノ秒です。

監視を定期的またはオンデマンドでトリガーするのは良いことですが、さらに前進したいと考えています。私たちはクライアントが実際に何を経験しているのかを知りたいと思っています。この目的を達成するために、クライアントが API を呼び出すたびに増加するアトミックカウンタに基づいて、FBClock API の内部にいくつかのバケットを埋め込みました。

これにより、クライアントがいつ問題を経験したかを明確に把握できるようになり、多くの場合、クライアントがそれに気づく前に確認できるようになります。

PTP プロトコル (特に ptp4l) には、(NTP や chrony とは異なり) クォーラム選択プロセスがありません。これは、クライアントがアナウンスメッセージ経由で提供される情報に基づいてタイムサーバーを選択し、信頼することを意味します。これは、タイムサーバー自体が間違っている場合にも当てはまります。

このような状況に備えて、線形化可能性チェックと呼ばれる最後の防御線を実装しました。

クライアントが 3 つのタイムサーバーを使用するように構成されており、クライアントが障害のあるタイムサーバー (タイムサーバー 2 など) にサブスクライブしている状況を想像してください。

この状況では、PTP クライアントはすべてが正常であると考えますが、不確実性のウィンドウがシフトされるため、時間のかかるアプリケーションに提供する情報は不正確になり、その結果不正確になります。

これに対処するために、FBCLOCK は並行して残りのタイムサーバーとの通信を確立し、結果を比較します。オフセットの大部分が高い場合、タイムサーバー 2 とクライアント間の同期が完全であっても、クライアントが従うサーバーが外れ値であり、クライアントが線形化できないことを意味します。

私たちは、PTP が今後数十年間でコンピュータネットワークで時刻を管理するための標準になると信じています。だからこそ、私たちはこれを前例のない規模で展開しています。私たちは、GNSS アンテナからクライアント API に至るまで、インフラストラクチャスタック全体を批判的に検討する必要があり、多くの場合、物事を最初から再構築することもありました。

私たちは PTP の展開を継続する中で、ネットワーク機器を製造するより多くのベンダーが私たちの取り組みを利用して、PTP をサポートする新しい機器を業界に導入することを期待しています。私たちは、ソースコードからハードウェアに至るまで、ほとんどの作業をオープンソース化しており、業界が私たちに協力して PTP を世界に提供してくれることを願っています。これらすべては、既存のソリューションのパフォーマンスと信頼性を向上させるという名目で行われてきましたが、将来的には新しい製品、サービス、ソリューションを開拓することも視野に入れています。

Meta の社内チームから、私たちと協力してくれるベンダーやメーカーに至るまで、この取り組みに関わったすべての人々に感謝したいと思います。時間愛好家たちを結びつけたアンドレイ・ルコヴェンコ氏に特別な感謝を捧げます。

この旅はまだ 1% 終わったところです。

PTP クロック精度 PTP クロッククラス、UTC オフセット