クロック同期

曖昧さ回避 「クロック同期設計」とは異なります。

クロック同期（クロックどうき、英語: clock synchronization）または時刻同期（じこくどうき）は、計算機科学や計算機工学の分野で、独立したコンピュータシステム間のクロック（時計）を同期させることである。システムのクロックは、最初は正確に設定されていたとしても、時間をカウントしているクロックのわずかなずれ（クロックドリフト（英語版））により、ある程度の時間が経過すると指し示す時間が異なってしまう。時計のずれの結果発生する問題と、それに対する解決策はいくつか存在する[1]。

用語[編集]

シリアル通信では、クロック同期とは、完全な位相同期（英語版）ではなく、周波数同期を実現するクロックリカバリ（英語版）を指すことがある。このようなクロック同期は、電気通信における同期（英語版）や自動ボーレート検出（英語版）で使用される[2]。

プレシオクロナス（英語版）（plesiochronous、準同期）やアイソクロナス（英語版）（isochronous）は、周波数同期と位相同期の緩い制約を持つシステムを指す。シンクロナス（synchronous）は、同期動作は、周波数だけでなく、時間に基づいたよりタイトな同期を意味する。

問題[編集]

小さなスケールでの時間管理の問題として、クロックスキューに関連した問題があるが、複数のコンピュータが同じグローバルな時間を実現する必要がある分散コンピューティングでは、問題がより複雑になる。

例えば、UNIXでは、makeコマンドを実行すると、新しいコードや変更されたコードのみがコンパイルされ、変更されていないコードの再コンパイルを回避しようとする。makeコマンドは、あるソースファイルを再コンパイルする必要があるかを決定するために、実行しているマシンの時計を使用する。ソースファイルが別のファイルサーバにあり、それぞれのサーバのクロックが同期されていない場合、makeプログラムは正しい結果を生成しない可能性がある[3]。

ストリーミングメディアを正しく再生するためには、クロック同期が必要である。クロック同期化は、Audio over Ethernet（英語版）システムの重要な要素である。

解決策[編集]

中央サーバを持つシステムでは、サーバがシステムの時間を決定するため、同期化の解決策は些細なものである。クリスティアンのアルゴリズム（英語版）とバークレーアルゴリズム（英語版）は、このような環境でのクロック同期問題に対する潜在的な解決策である。

分散コンピューティングでは、グローバルな時間が容易にはわからないため、この問題はより複雑になる。インターネット上で最も使用されているクロック同期法は、UDPでのメッセージのやり取りに基づく階層クライアント・サーバー・アーキテクチャであるNetwork Time Protocol (NTP)である。ランポートタイムスタンプ（英語版）とベクタークロック（英語版）は、分散コンピューティングにおける論理クロック（英語版）の概念である。

無線ネットワーク（英語版）では、無線媒体上での同期パケットの衝突の可能性や、低コストの無線機器ではクロックのドリフト率が高くなるため、問題はさらに難しくなる[4][5]。

バークレーアルゴリズム[編集]

詳細は「en:Berkeley algorithm」を参照

バークレーアルゴリズムは、電波時計などの時刻源がないシステムでも使用できるが、このシステムでできるのはグローバル時間としてグローバル平均時間を維持するだけで、実際の時間と同期させる方法はない。タイムサーバは定期的に全てのタイムクライアントから時間を取得し、その結果を平均化して、求められた平均値に合わせるためにローカルクロックを調整する必要があることをクライアントに通知する。このアルゴリズムは、内部クロックにおいて、それが指し示す時間だけでなく、クロックレートも変化するという事実に基づいている。

CS-NMS[編集]

クロックサンプリング相互ネットワーク同期（CS-MNS、Clock-sampling mutual network synchronization）は、分散型や移動体通信への応用に適している。CS-MNSは、間接的にリンクされた非隣接ノードを含むメッシュネットワーク上でスケーラブルであることが示されており、IEEE 802.11や同様の規格と互換性がある。数マイクロ秒のオーダーまで正確に同期できるが、隣接ノード間のリンクがリンク遅延が無視できるほど（1マイクロ秒未満）の直接物理的な無線接続である必要があるため、隣接ノード間の距離が数百メートルに制限される[6]。

クリスティアンのアルゴリズム[編集]

詳細は「en:Cristian's algorithm」を参照

クリスティアンのアルゴリズムは、タイムサーバの存在に依存している[7]。タイムサーバは、電波時計などの正確な時間源を使用してその時刻を維持し、システム内の他の全てのコンピュータはそれに接続する。タイムクライアントは、タイムサーバへの手続き呼び出しを行うことで、そのクロックを維持する。このアルゴリズムの変種では、ネットワーク無線伝搬時間を考慮に入れることで、より正確な時間計算が可能になる。

GPS[編集]

グローバル・ポジショニング・システム(GPS)は、ナビゲーションの他に、時計の同期にも利用できる。GPSの時間信号の精度は±10ナノ秒である[8]。

IRIGタイムコード[編集]

IRIGタイムコード（英語版）(Inter-range Instrumentation Group time code)は、タイミング情報を転送するための標準フォーマットである。精密なタイミングのために設計された原子周波数標準やGPS受信機には、IRIG出力が装備されていることが多い。この標準は、米軍の発射場司令官協議会の標準化団体である射程間計装グループ（英語版）(IRIG)の通信ワーキンググループによって作成された。この規格のための作業は1956年10月に開始され、オリジナルの規格は1960年に承認された[9]。

NTP[編集]

Network Time Protocol (NTP)は非常に堅牢なプロトコルで、インターネット全体で広く使用されている。長年にわたってテストされており、一般的に信頼性（英語版）の低いネットワーク用の分散型時刻同期プロトコルの最先端とみなされている。このプロトコルは、インターネット上では数ミリ秒単位の時間に、LAN上ではサブミリ秒単位の時間に同期オフセットを削減することができる。ネットワーク遅延計算、コンピュータ負荷の安定度など多岐にわたる計測アルゴリズムを搭載する。時計をコンピュータ機器に反映する方式は、いくつか提案されているが実装者による選択となっている。

NTP プロトコルの簡略化されたバージョンであるSimple Network Time Protocol (SNTP) もマスタースレーブ型時刻同期プロトコルとして使用できるが、NTPの洗練された機能を欠くため、パフォーマンスと信頼性のレベルがはるかに低くなっている。SNTPは時計同期精度に関する規約はなく、実装者による設定が精度となる。

PTP[編集]

Precision Time Protocol (PTP)は、IEEE1588に基づきLAN上で高精度で時間を配信するためのマスタースレーブプロトコルである。タイムスタンプ精度は、10マイクロ秒以下としている。ただし、IEEE1588に対応するハードウェアを搭載していない機器では、NTPと同じ程度の精度となる。

RBS[編集]

Reference Broadcast Synchronization（英語版） (RBS)アルゴリズムは、無線ネットワークやセンサーネットワークでよく使用されている。この方式では、イニシエータが参照メッセージをブロードキャストして、受信者に自分の時計を調整するように促す。

RBIS[編集]

Reference Broadcast Infrastructure Synchronization（英語版） (RBIS)[10]プロトコルは、RBSのように、受信機＝受信機同期パラダイムに基づくマスタースレーブ同期化プロトコルである。これは、インフラストラクチャモードで構成されたIEEE 802.11ワイヤレスネットワークで使用するように調整されている。このプロトコルは、アクセスポイントへの変更を必要としない。

同期イーサネット[編集]

同期イーサネット（英語版）(Synchronous Ethernet)、何らかの同期プロトコル（ホワイトラビットプロジェクト（英語版）の場合はPTP）と組み合わせることで、サブナノ秒の同期精度を実現するように、イーサネットを同期的に使用する。

無線アドホックネットワーク[編集]

無線アドホックネットワーク（英語版）では、マルチホップ（英語版）で同期メッセージを送信し、各ノードが同期メッセージの直接の送信者であるノードと順次同期することで、同期を実現している。例として、Flooding Time Synchronization Protocol(FTSP)[4]やHarmonia[5]があり、いずれもマイクロ秒オーダーの精度で同期を達成することができる。

関連項目[編集]

脚注[編集]

[脚注の使い方]
  1. ^ Tanenbaum, Andrew S.; van Steen, Maarten (2002), Distributed Systems : Principles and Paradigms, Prentice Hall, ISBN 0-13-088893-1 
  2. ^ Norman Matloff (September 3, 2001), Transmission on a Serial Line, http://heather.cs.ucdavis.edu/~matloff/Networks/Serial/Serial.pdf 2018年4月17日閲覧。 
  3. ^ Marco Platania (2018年6月3日). “Clock Synchronization”. p. 11. 2020年6月23日閲覧。
  4. ^ a b Maróti, Miklós; Kusy, Branislav; Simon, Gyula; Lédeczi, Ákos (2004). “The Flooding Time Synchronization Protocol”. Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems. SenSys '04 (New York, NY, USA: ACM): 39–49. doi:10.1145/1031495.1031501. ISBN 1581138792. 
  5. ^ a b Koo, Jinkyu; Panta, Rajesh K.; Bagchi, Saurabh; Montestruque, Luis (2009). “A Tale of Two Synchronizing Clocks”. Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems. SenSys '09 (New York, NY, USA: ACM): 239–252. doi:10.1145/1644038.1644062. ISBN 9781605585192. 
  6. ^ Rentel, Carlos H.; Kunz, Thomas (March 2005), “A clock-sampling mutual network synchronization algorithm for wireless ad hoc networks”, IEEE Wireless Communications and Networking Conference (IEEE Press) 1: 638–644, doi:10.1109/WCNC.2005.1424575 
  7. ^ Cristian, F. (1989), “Probabilistic clock synchronization”, Distributed Computing (Springer) 3 (3): 146–158, doi:10.1007/BF01784024 
  8. ^ “Common View GPS Time Transfer”. National Institute of Standards and Technology. 2012年10月28日時点のオリジナルよりアーカイブ。2020年6月23日閲覧。
  9. ^ Josh Matson (2013年5月). “Choosing the correct Time Synchronization Protocol and incorporating the 1756-TIME module into your Application”. Rockwell Automation. 2019年8月13日閲覧。
  10. ^ Cena, G.; Scanzio, S.; Valenzano, A.; Zunino, C. (June 2015), “Implementation and Evaluation of the Reference Broadcast Infrastructure Synchronization Protocol”, IEEE Transactions on Industrial Informatics (IEEE Press) 11 (3): 801–811, doi:10.1109/TII.2015.2396003 

外部リンク[編集]

「https://ja.wikipedia.org/w/index.php?title=クロック同期&oldid=86273219」から取得