異機種環境での時間同期

Question 1

[編集] 昔の回答を記憶から書き留めただけなので、参考文献を付けて大幅に書き直しました。

短い答え：いいえ。現在、x86/x64 プラットフォーム上の一般的なオペレーティングシステムから、ミリ秒に近い精度を得ることは不可能です。

免責事項 これは素人の回答です。私は普通のシステム管理者であり、コンピュータに関して普通のシステム管理者の見解を持っています。時間管理に関するプロレベルの知識は、カーネル開発者やハードウェア設計者の中にあると思われます。

長い答え:

どこかから始めなければなりません。私はこれをトップダウンで、まずアプリケーションから始めて発振器に向かって下へ進んでいきます。

最初の問題は、1 台のコンピューターで時刻を管理することではなく、環境全体で、どのような時刻管理でも合意できるようにすることです。時刻管理とは何でしょうか。今日のコンピューターでは、時刻を管理する方法がいくつかあることがわかりました。最もよく目にするのは、システム時間です (画面の隅に表示されます)。まずは、それが単純なものだと仮定して、数段落後に複雑なものを説明します。

システム時刻は正確で、すべてのコンピュータで均一であることが必要です。どのような要件であってもそれを満たすには、信頼できるソースから非常に細かいレベルでシステム時刻を伝達する方法が必要です。

要件を 1 ミリ秒の許容レベルにしましょう。つまり、環境内で時間が 1 ミリ秒ずれたり、重要な目標が達成できなかったりする可能性があるということです。具体的に、Microsoft が私たちに何ができるかを見てみましょう。

NT などの旧式を除き、Windows ネイティブは、簡略化された ntp (XP/2003 以降のドメインに参加しているコンピュータ) または簡略化された sntp (Win2k 以降のドメインに参加していないコンピュータ) に基づいてタイムキーピングを実行します。この詳細を指摘してくれた @Ryan に感謝します。マイクロソフトは2つの目標を設定計時実装を行う際には、どちらにも私たちが望むレベルの精度は含まれていません。

「ネットワーク上のノード間の W32Time サービスの精度については保証もサポートも行いません。W32Time サービスは、時間に敏感なアプリケーションのニーズを満たすフル機能の NTP ソリューションではありません。W32Time サービスは、主に次のことを行うように設計されています。

Kerberos バージョン 5 認証プロトコルを機能させます。
クライアントコンピューターに緩やかな同期時間を提供します。

W32Time サービスは、同期時間を 1 ～ 2 秒の範囲で確実に維持できません。このような許容範囲は、W32Time サービスの設計仕様の範囲外です。"

わかりました。サービススタックを複数のコンピューターで実行していて、イベント相関のタイムキーピング許容レベルが 1 ミリ秒に近づいていると仮定すると、これはかなり残念なことです。サービススタックに 2 台のコンピューターが含まれている場合、Windows ネイティブタイムキーピングはまったく使用できません。しかし、ついでに、Windows ネイティブタイムキーピングに関する重要なポイントを 1 つまたは 2 つ強調し、詳細なドキュメントも含めましょう。

AD がある場合、特定のドメインの時刻は、どの DC が PDC エミュレーターロールを持っているかに関係なく、PDC エミュレーターロールから同期されることに注意してください。したがって、ドメインに正しい時刻を持ち込むには、PDC エミュレーターロールを実行しているドメインコントローラーを介して行う必要があります。マルチドメインフォレストの場合、これはフォレストルートドメインの PDC エミュレーターに変換されます。そこから、時刻は主にサブドメインの PDC エミュレーターと各ドメインメンバーにファンアウト方式で分散されます (いくつかの注意点があります)。このプロセスは、ここに文書化されているさらに詳しい情報ここ

わかりました。何ができるでしょうか?

まず、必要なのは1つまたは他の環境全体で時間を同期するより正確な方法。Linux ntpdを実行できないと仮定すると、Windows 用の ntpdシェアウェアクライアントの「ターディスしかし、試してみる価値のあるものは他にもたくさんあるはずです。

私たちは、非常に大きなスキューを持つ CMOS クロックを持つ PDC エミュレーターとして動作する Win2k3 サーバー上で Tardis を実行していましたが、説明のつかない歴史的理由により、そこからネットワーク全体を同期する以外に選択肢がありませんでした。今では、外部の原子時計から時間を取得する専用の Linux ntpd に置き換えられて大変喜ばしいことですが、Tardis は当時、私たちを見事に救ってくれました。ただし、Windows ネイティブよりも高い精度を実現するのに役立つかどうかはわかりません。

しかし、ここからは、私たちが完璧な代替ネットワーク時間同期を実装する方法を編み出したと仮定しましょう。その固有の巧妙さにより、1 ミリ秒未満の許容レベルに対応できます。AD がネットワーク全体に時間がどのように広がると予想するかを強制するために、これを導入しました。

これは、オペレーティングシステムとマイクロサービスから 1 ミリ秒に近い粒度で正確な診断を取得できることを意味しますか?

x86/x64 アーキテクチャ上のオペレーティングシステムがプロセッサ時間をどのようにスケジュールするかを見てみましょう。

割り込みを使用する。考古学的資料が豊富な多面的な獣ただし、割り込みを希望しているのはオペレーティングシステムだけではありません。ハードウェアも割り込みを希望しており、そのための手段を持っています。(キーボードの登場です) そしてオペレーティングシステムはそれに従います。

ここからが複雑になるので、私はこれを単純化して解決します。質問がありますか？私は身をかがめて、身を隠し、この主題に関する非常に優れた論文（Windowsプラットフォームでミリ秒を探しているなら、ぜひ読んでみてください。）Win8.1/Win2012r2用の更新バージョンは進行中と報じられているしかし、発売日はまだ発表されていない。

さて、割り込みです。OSで何かが起きるたびに、割り込みがそれに続くアクションをトリガーします。アクションとはカーネルからフェッチされる一連の命令であり、沢山の異なるマナー肝心なのは、割り込みが発生した時刻はハードウェアアーキテクチャとカーネルの割り込み処理によって多少の精度で判断できるものの、その後の実行部分が発生する正確な時刻は一般には判断できないということです。特定の命令セットは割り込みの直後に実行される場合もあれば、遅く実行される場合もあります。予測可能な順序で実行される場合もあれば、そうでない場合もあります。バグのあるハードウェアや、認識すら困難な遅延に影響を与えるドライバの不備が原因である場合もあります。ほとんどの場合、まったくわかりません。後続のログファイルに表示されるミリ秒単位のタイムスタンプは、非常に正確ですが、イベントがいつ発生したかについては正確ですか?

タイムキーピング割り込みについて少し考えてみましょう。割り込みには優先度レベルがあり、最も低いレベルではユーザーアプリケーション (標準サービスなど) がプロセッサ時間を取得します。他の (より高い) レベルはハードウェアとカーネル作業用に予約されています。最低レベルより上のレベルの割り込みが到着すると、システムはキューにある優先度の低い割り込みが存在しないものとみなします (優先度の高い割り込みが処理されるまで)。このようにして、実行中の通常のアプリケーションとサービスはプロセッサ時間の最後尾に配置されます。対照的に、クロック割り込みにはほぼ最高の優先度が与えられます。時間の更新は、システム内でほぼ常に実行されます。これは、すべての仕組みをほとんど犯罪的に単純化しすぎていますが、この回答の目的には役立ちます。

更新時間は実際には 2 つのタスクで構成されます。

システム時間の更新 / 別名、壁時計 / 別名、誰かに時刻を尋ねられたときに私が答える言葉 / 別名、ntp が近くのシステムに対して少し前後に調整するもの。
コード実行の期間を測定するときなどに使用されるティックカウントを更新します。

しかし、ウォールタイムであれティックカウントであれ、システムはどこから時間を取得するのでしょうか？それはハードウェアアーキテクチャに大きく依存します。ハードウェアのどこかで1つまたは複数のオシレータが刻み、その刻みは1つのいくつかの可能パスカーネルと通信するためのインターフェースに変換され、より高い精度と正確さでウォールタイムとティックカウントが更新されます。

マルチコアシステムにおける発振器配置にはいくつかの設計モデルがありますが、主な違いは同期配置と非同期配置のようです。これらと、正確な計時に対するそれぞれの課題について説明します。ここ例えば。

つまり、同期タイムキーピングでは、マルチコアごとに 1 つのリファレンスクロックがあり、その信号がすべてのコアに配信されます。非同期タイムキーピングでは、コアごとに 1 つのオシレータがあります。最新の Intel マルチコアプロセッサ (Haswell) では、「QuickPath Interconnect」と呼ばれるシリアルバスと「Forwarded Clocking」を使用した何らかの形式の同期設計が使用されていることに注意してください (ref)。データシートフォワードクロッキングは素人（私）でも表面的に理解できるような言葉で説明されている。ここ。

さて、オタクっぽい話はここまでにして（時間管理が複雑で実用的なタスクであり、多くの歴史があることを示しました）、割り込み処理をさらに詳しく見てみましょう。

オペレーティングシステムは、ティックまたはティックレスという 2 つの異なる戦略のいずれかを使用して割り込みを処理します。システムではどちらか一方が使用されていますが、これらの用語の意味は何でしょうか。

刻々と変化するカーネル一定の間隔で割り込みを送信します。OS はティック間隔よりも細かい解像度で時間を測定できません。それでも、1 つまたは複数のアクションを実行する際に実際に行われる処理には、ティック間隔よりも大きな遅延が含まれる可能性があります。たとえば、サービス間の呼び出しに固有の遅延によって比較的多くの時間がかかる可能性がある分散システム (マイクロサービスなど) を考えてみましょう。しかし、すべての命令セットは、OS によってカーネルのティック時間よりも細かい解像度で測定される 1 つまたは複数の割り込みに関連付けられます。ティック時間には基本値がありますが、少なくとも Windows では、個々のアプリケーションによって要求に応じて減らすことができます。これは、関連するアクションです。利益だけでなくコストも、そして運ぶ細かい文字がかなり多いそれと。

いわゆるティックレスカーネル(非常に説明的でない名前が付けられています) は比較的新しい発明です。ティックレスカーネルは、ティック時間を可変間隔 (可能な限り長い期間) に設定します。その理由は、OS がプロセッサコアが可能な限り長くさまざまなレベルのスリープ状態に入ることを動的に許可するためで、目的は電力を節約することです。「さまざまなレベル」には、命令をフルスピードで処理すること、減速速度 (つまり、プロセッサ速度が遅い) で処理すること、またはまったく処理しないことが含まれます。異なるコアは異なる速度で動作することが許可されており、ティックレスカーネルは、割り込みバッチで命令をキューに入れて実行する場合であっても、プロセッサを可能な限り非アクティブにしようとします。つまり、マルチプロセッサシステム内の異なるコアは、互いに対して時間的にドリフトすることが許可されています。もちろん、これは正確な時間管理に悪影響を及ぼし、新しい省電力プロセッサアーキテクチャと、効率的な省電力を可能にするティックレスカーネルでは、今のところ未解決の問題です。これを、実際の作業を受け取っているかどうかに関係なく、すべてのプロセッサコアを継続的に起動するティックカーネル (静的ティック間隔) と比較してください。ティックカーネルでは、時間管理にある程度不正確さはありますが、ティックレスカーネルと比較すると比較的信頼できる程度です。

標準Windowsのティックタイム（システム解像度）は15.6ミリ秒です。Windows 8/2012までは、デフォルトの動作はティックレスでした（ただし、ティックカーネルに戻すことは可能です）。Linuxのデフォルトのティック時間はカーネルのコンパイルに依存すると思いますが、このニッチは私の経験の範囲外（そしてこれですこれも) なので、これに依存している場合は再確認することをお勧めします。Linux カーネルは 2.6.21 から tickless でコンパイルされていると思いますが、tickless の動作を最適化するさまざまなフラグを使用してコンパイルされている可能性があります (no_hz のいくつかのバリエーションしか覚えていません)。

ベアメタルシステムでは、状況はさらに悪化します。VMとハイパーバイザーの競合がさまざまな形で発生し、正確な時間管理が極めて困難になります。VMwareの概要そしてRHEL KVM用のものはこちら分散システムでも同じことが言えます。クラウドシステムはさらに困難実際のハイパーバイザーやハードウェアを実際に見る機会さえないからです。

結論として、システムから正確な時間を取得することは、多層的な問題です。高レベルの観点からボトムアップで進むと、ハードウェアとカーネル間の内部時間同期、割り込み処理、時間を取得したい命令の実行の遅延、仮想環境では第 2 の OS レイヤーのカプセル化による不正確さ、分散システム間の時間同期を解決する必要があります。

したがって、コンピューティングの歴史のこの時点では、少なくとも一般的なオペレーティングシステムを使用した場合、x86/x64 アーキテクチャからミリ秒レベルの精度を得ることはできません。

しかし、どこまで近づけるのでしょうか？それは分かりませんし、システムによって大きく異なるはずです。自分の特定のシステムにおける不正確さを把握するのは大変な作業です。インテルがコードベンチマークの実施方法を提案この観点から見ると、私がたまたま管理しているような通常のシステムは、まったく制御不能であることがわかります。

私は達成することさえ考えていない「すべての電力最適化、Intel ハイパースレッディングテクノロジー、周波数スケーリング、ターボモード機能がオフになりました」クリティカルなシステムでは、C のコードラッパーをいじったり、その後の回答を得るために長期テストを実行したりすることはほとんどありません。私は、それらを生きたままにして、あまり邪魔することなく、それらについてできるだけ多くのことを学ぶようにしています。timestamp さん、ありがとうございます。完全に信頼できないことはわかっていますが、それほど多くの秒数ずれていないことはわかっています。実際のミリ秒の精度が重要になると、1 つの測定では十分ではなく、パターンを確認するためにより多くの測定が必要になります。他に何ができるでしょうか。

最後に、興味深いのはリアルタイムOSの開発者は割り込み遅延をどう考えているかもあります非常にエキサイティングな時間同期の代替かなり興味深い作品が進行中です統計、方法論そして白い紙公開されています。これに将来のハードウェアアーキテクチャとカーネルの開発を加えると、数年後にはこの時間計測の精度の問題はそれほど問題ではなくなるかもしれません。そう願う人もいるでしょう。

Answer