異種環境での時刻同期
マシンがWindows（ほとんど）、Linux（少数）で実行できる混合環境では、時々Android ...に近い精度で時刻同期を行うための最良のソリューションは何ですかミリ秒？
マイクロサービスベースのソリューションを開発しています。このソリューションでは、セットアップ内の複数のマシンにサービスが分散しています。それらの間の情報（ログ、監視など）を統合するには、共通のタイムベースが必要な多くの状況があります。
WindowsでNTPを使用すると、制限が共有されるようです。そのオペレーティングシステムで実行できるオープンソースソリューションはありますか？セットアップにLinuxマシンが常に存在することを保証することはできません。 。
[編集]メモリから古い答えを書き留めたので、参照を使用して大幅に書き直しました。
簡単な答え：いいえ。現在、x86/x64プラットフォームの一般的なオペレーティングシステムからミリ秒に近い精度を得るのは不可能です。
[〜＃〜]免責事項[〜＃〜]私は普通のシステム管理者であり、普通のシステム管理者なので、これは素人の答えですコンピューターのsysadminsビュー。タイムキーピングに関する専門的なレベルの知識は、一部のカーネル開発者やハードウェアアーキテクトに見られる可能性があります。
長い答え：
どこかから始めなければなりません。アプリケーションをオシレーターに向かって下に移動することから始めて、これをトップダウンで行います。
最初の問題は、1台のコンピューターで時間管理を行うことではなく、環境全体で時間管理について合意することです。どのような計時？今日のコンピューターで時間を保つには、いくつかの方法があることがわかりました。私たちが最もよく目にするのはシステム時間です（画面の隅の1つに表示されます）。数段落下の単純で複雑なもののふりをすることから始めましょう。
システム時刻を正確にし、すべてのコンピューターで均一にする必要があります。信頼できるソースから、要件がどのようなものであっても満たすように、非常にきめ細かいレベルで通信する方法が必要です。
要件を1ミリ秒の許容レベルにしましょう。つまり、環境内で時間が1ミリ秒ずれたり、重要な目標を達成できなかったりする可能性があります。具体的に見て、マイクロソフトが私たちのために何ができるかを見てみましょう。
NTなどの廃止されたものを除いて、Windowsネイティブは、簡略化されたntp（XP/2003以降のドメインに参加しているコンピューター）または簡略化されたsntp（Win2k以降のドメインに参加していないコンピューター）のいずれかに基づいてタイムキーピングを実行します-この詳細を無視してくれた@Ryanに感謝します。 Microsoftは2つの目標を設定しました 時間管理の実装を行うとき、どちらにも必要なレベルの精度が含まれていません。
"ネットワーク上のノード間のW32Timeサービスの正確性を保証およびサポートしていません。W32Timeサービスは、フル機能のNTPソリューションではありません。時間に敏感なアプリケーションのニーズを満たします。W32Timeサービスは、主に次のことを行うように設計されています。
- Kerberosバージョン5認証プロトコルを機能させます。
- クライアントコンピューターに緩い同期時間を提供します。
W32Timeサービスは、同期時間を1〜2秒の範囲に確実に維持できません。このような許容範囲は、W32Timeサービスの設計仕様の範囲外です。 "
OK。サービススタックを複数のコンピューターで実行していて、イベント相関のために1msに近い時間管理の許容レベルがあると仮定すると、これはかなりの失望です。サービススタックに2台のコンピューターが含まれている場合、実際にはWindowsのネイティブタイムキーピングをまったく使用できません。しかし、その間、Windowsネイティブの時間管理に関する重要なポイントを1つか2つ強調し、いくつかの完全なドキュメントを含めましょう。
ADがある場合は、特定のドメインの時間がPDCエミュレーターの役割から同期されることを確認してください。DCのいずれかがあります。正しい時刻をしたがって、ドメインはPDCエミュレーターの役割を実行しているドメインコントローラーを経由する必要があります。マルチドメインフォレストの場合、これはフォレストルートドメインのPDCエミュレーターに変換されます。そこから、時間は主にPDCサブドメインのエミュレーターと各ドメインメンバーにファンアウト方式で分散されます（いくつかの注意点があります）。このプロセスは ここに記載 です。さらに詳細な情報 ここ
OK。私たちは何ができる？
まず、 one または other 環境全体で時間を同期するためのより正確な方法が必要です。 Linux ntpdまたは ntpd for Windows を実行できないと仮定すると、 Tardis というシェアウェアクライアントを見ることができますが、試してみることがもっとたくさんある可能性があります。
PDCエミュレーター、CMOSクロック、非常に大きなスキュー）として実行されているWin2k3サーバーでTardisを実行しました。これは、説明できない歴史的な理由から、ネットワーク全体をそこから同期します。今では、専用のLinux ntpdが外部のアトミッククロックから時間をもたらすことに大喜びに置き換えられましたが、Tardisはその場で見事に私たちを救ってくれました。私はしませんただし、Windowsネイティブよりも高い精度を達成するのに役立つかどうかを知ってください。
しかし、この時点から、完全な代替ネットワーク時刻同期を実装する方法を理解したと仮定しましょう。その固有の巧妙さにより、1ミリ秒未満の許容レベルに対応できます。 ADがネットワーク全体に広がる時間をどのように予測するかを強制するために、これを導入しました。
これは、オペレーティングシステムとマイクロサービスから1ミリ秒に近い粒度で正確な診断を取得できることを意味しますか？
X86/x64アーキテクチャのオペレーティングシステムがプロセッサ時間をどのようにスケジュールするかを見てみましょう。
彼らは割り込みを使用します、それは 考古学的物質が豊富な多面的な獣 です。ただし、中断したいのはオペレーティングシステムだけではありません。ハードウェアも割り込みを望んでおり、それを実行する手段があります。 （こんにちはキーボード）そしてオペレーティングシステムは一緒に遊んでいます。
これはそれが複雑になるところです、そして私は過度に単純化することによってこれを解決します。質問？私はあなたをダックし、カバーし、そしてあなたに 主題に関する絶対に優れた論文 を指摘します。 （Windowsプラットフォームでミリ秒を探している場合は、実際に読んでください。）Win8.1/Win2012r2の更新バージョンは 報告によると作業中 ですが、リリース日はまだ明らかにされていません。
OK、中断します。 OSで何かが発生した場合は常に、割り込みが次のアクションをトリガーします。アクションは、カーネルからフェッチされた一連の命令であり、 ロット全体 または さまざまな方法 で実行できます。要するに、ハードウェアアーキテクチャとカーネル割り込み処理に応じて多かれ少なかれ正確に決定できる時間に割り込みが発生するにもかかわらず、実行の後続の部分が発生する正確な時間は一般にできないということです。特定の一連の命令は、割り込み後の早い段階または遅い段階で実行される場合があり、予測可能な順序で実行される場合とそうでない場合があります。バグのあるハードウェアまたはドライバーの記述が不十分な場合、レイテンシーに影響を及ぼし、認識すら困難になる可能性があります。ほとんどの場合、人は単に知りません。後続のログファイルに表示されるミリ秒レベルのタイムスタンプ- 非常に正確ですが、イベントがいつ発生したかについては正確ですか？
計時の中断で一時停止しましょう。割り込みには優先度レベルがあり、最低レベルはユーザーアプリケーション（標準サービスなど）がプロセッサ時間を取得する場所です。他の（より高い）レベルは、ハードウェアとカーネル作業のために予約されています。最低レベルを超える割り込みが到着した場合、システムは、キュー内にも優先度の低い割り込みが存在しないふりをします（優先度の高い割り込みが処理されるまで）。このようにして、実行中の通常のアプリケーションとサービスは、プロセッサ時間の最後の列になります。対照的に、クロック割り込みはほぼ最高の優先順位が与えられます。時間の更新は、ほぼ常にシステムで行われます。これは、すべてがどのように機能するかをほぼ犯罪的に過度に単純化したものですが、この回答の目的を果たしています。
更新時間は、実際には2つのタスクで構成されています。
システム時刻の更新/ AKAウォールクロック/ AKA誰かが私に今何時かと尋ねたときに私が言うこと/ AKA ntpは、近くのシステムに対して少し前後にいじります。
ティックカウントの更新。たとえば、コード実行の期間を測定するときに使用されます。
しかし、それが実時間であろうとティックカウントであろうと、システムはどこから時間を取得しますか？それはハードウェアアーキテクチャに大きく依存します。ハードウェアのどこかで1つまたは複数のオシレータがカチカチ音をたてており、そのカチカチ音は one of several possible paths を介してインターフェイスに送られ、カーネルは、精度と精度が多かれ少なかれ、壁時間とティックカウントを更新します。
マルチコアシステムでの発振器配置にはいくつかの設計モデルがあり、主な差別化要因は同期配置と非同期配置のようです。これらは、正確な時間管理に対するそれぞれの課題とともに説明されています ここ たとえば。
つまり、同期タイムキーピングにはマルチコアごとに1つの基準クロックがあり、その信号がすべてのコアに分散されます。非同期タイムキーピングには、コアごとに1つのオシレータがあります。最新のIntelマルチコアプロセッサ（Haswell）は、「ForwardedClocking」を備えた「QuickPathInterconnect」と呼ばれるシリアルバスを使用した何らかの形式の同期設計を使用していることに注意してください。 データシート 。 Forwarded Clockingは、素人（私）がそれをすばやく表面的に把握できるように説明されています ここ 。
さて、すべての神経質が邪魔にならないように（これは、時間管理がそれについて多くの生きた歴史を持つ複雑な実用的なタスクであることを示すのに役立ちました）、割り込み処理をさらに詳しく見てみましょう。
オペレーティングシステムは、ティックまたはティックレスという2つの異なる戦略のいずれかを使用して割り込みを処理しました。システムはどちらか一方を使用しますが、これらの用語はどういう意味ですか？
チェックカーネルは一定の間隔で割り込みを送信します。 OSは、ティック間隔よりも細かい解像度で時間を測定することはできません。それでも、1つまたは複数のアクションの実行に関連する実際の処理には、ティック間隔よりも大きい遅延が含まれている可能性があります。たとえば、サービス間呼び出しに固有の遅延が比較的多くの時間を消費する可能性がある分散システム（マイクロサービスなど）について考えてみます。ただし、すべての命令セットは、カーネルのティック時間よりも細かい解像度でOSによって測定された1つまたは複数の割り込みに関連付けられます。ティック時間には基本値がありますが、少なくともWindowsでは、個々のアプリケーションの要求に応じて減らすことができます。これは、 メリットだけでなくコストも に関連付けられたアクションであり、 かなり細かい印刷 を伴います。
いわゆる ティックレスカーネル（非常にわかりにくい名前を持っています）は比較的新しい発明です。ティックレスカーネルは、ティック時間を可変間隔で設定します（将来的に可能な限り長い期間）。その理由は、電力を節約するという単純な目的で、OSがプロセッサコアを可能な限り長い間さまざまなレベルのスリープ状態に動的に移行できるようにするためです。 「さまざまなレベル」には、フルスピードでの命令の処理、デクリエイテッドレートでの処理（つまり、プロセッサ速度の低下）、またはまったく処理されないことが含まれます。異なるコアは異なるレートで動作することが許可されており、ティックレスカーネルは、割り込みバッチでプロセッサを起動するためのキューイング命令を含む場合でも、プロセッサを可能な限り非アクティブにしようとします。つまり、マルチプロセッサシステムのさまざまなコアは、相互に時間的にドリフトすることができます。もちろん、これは適切な時間管理で大混乱を引き起こし、効率的な省電力を可能にする新しい省電力プロセッサアーキテクチャとティックレスカーネルではこれまでのところ未解決の問題です。これを、実際の作業を受け取っているかどうかに関係なく、すべてのプロセッサコアを継続的にウェイクアップするティックカーネル（静的ティック間隔）と比較してください。タイムキーピングはある程度不正確ですが、ティックレスカーネルと比較して比較的信頼できる程度です。
標準 Windowsティック時間-つまりシステム解像度-は15.6ms Windows 8/2012までは、デフォルトの動作はティックレスです（ただし、ティックカーネルに戻すことができます）。 Linuxのデフォルトのティック時間はカーネルのコンパイルに依存すると思いますが、 このニッチ は 私の経験からかなり外れています （そして これも ）あなたがそれに依存しているかどうかを再確認したい。私が信じているLinuxカーネルは、2.6.21からティックレスでコンパイルされており、ティックレス動作を最適化するさまざまなフラグを使用してコンパイルできます（そのうち、no_hzのいくつかのバリアントのみを思い出します）。
ベアメタルシステムについてはこれだけです。仮想システムでは、VMとさまざまな方法でのハイパーバイザーの競合により、正確な時間管理が非常に困難になるため、さらに悪化します。これが VMwareの概要 および ここにあります） 1つはRHELKVM用です 。同じことが分散システムにも当てはまります。クラウドシステムは さらに難しい 実際のハイパーバイザーとハードウェアを見るのにさえ近づかないためです。
結論として、システムから正確な時間を取得することは、多層的な問題です。ここで、高レベルの観点からボトムアップで解決する必要があります。ハードウェアとカーネル間の内部時刻同期、割り込み処理、および仮想環境が不正確な場合は、希望する命令の実行の遅延2番目のOSレイヤーのカプセル化により、分散システム間の時刻の同期。
したがって、コンピューティングの歴史のこの時点では、少なくとも一般的なオペレーティングシステムを使用しない限り、x86/x64アーキテクチャからミリ秒レベルの精度を得ることができません。
しかし、どれだけ近づくことができますか？私にはわかりませんが、システムによって大きく異なるはずです。自分の特定のシステムの不正確さを把握することは困難な作業です。 Intelがコードベンチマークを実行するように提案する方法 を見るだけで、私が管理しているシステムなど、通常のシステムがこの観点から非常に制御不能になっていることがわかります。
重要なシステムでは、「すべての電力最適化、Intelハイパースレッディングテクノロジー、周波数スケーリング、ターボモード機能がオフになっている」を達成することすら考えていません。 Cで、その後の回答を得るために長期テストを実行します。私はただ彼らを生かし続け、彼らをあまり邪魔することなく彼らについてできるだけ多くを学ぶようにしています。タイムスタンプをありがとう、私はあなたを完全に信頼できないことを知っていますが、あなたがあまり多くの秒を離れていないことは知っています。実際のミリ秒の精度が重要になる場合、1つの測定では不十分ですが、パターンを検証するには、より多くの測定が必要になります。他に何ができますか？
最後に、 リアルタイムOSの人々が割り込みレイテンシをどのように考えているか を見るのは興味深いことです。また、作品には 非常にエキサイティングな時間同期の代替 があり、かなり興味深い 統計 、 方法論 および ホワイトペーパー 公開されます。それに将来のハードウェアアーキテクチャとカーネル開発を追加すると、数年後には、この計時精度の問題はもはやそのような問題ではなくなる可能性があります。希望するかもしれません。
ネイティブのtime.windows.comは、Microsoftオペレーティングシステムによって使用されます。より具体的なものが必要な場合は、 NIST Internet Time Server を使用することをお勧めします。改ざんが懸念される場合は、認証済みNTPを実行します。それでも不十分な場合は、いつでも独自に実行できます。ストラタム1または2を販売するベンダーは多数あります= NTPネットワークに接続するだけのサーバー。Stratumは時間を確認するために使用されるさまざまな方法を指します。Stratum1は1つの方法（NTP、CDMA、GPS）のみを使用しますが、Stratum2は2つの方法を使用します。メソッド。