私のコンピューターはどこから時刻を取得しているのか？

 (dotat.at)
5 ポイント 投稿者 GN⁺ 2023-10-06 | 1件のコメント | WhatsAppで共有
  • コンピューターの時刻は通常 NTP から始まるが、その背後には基準時計、GPS、米国海軍天文台、国際時刻標準へと続く長いサプライチェーンがある
  • stratum 1 NTPサーバーは MSF・DCF77 のような無線信号や GPS 受信機を基準時計として用い、実環境では GPS が一般的な時刻源になっている
  • GPS時刻はコロラド州の Schriever Space Force Base、US Naval Observatory Alternate Master Clock、ワシントンDCの US Naval Observatory へとたどれる
  • UTCは原子時計の時刻と 地球自転 を合わせるための標準であり、IERS の Bulletin C と BIPM の Circular T がうるう秒と公式UTCとの差を管理している
  • 現在の秒のセシウム基準の定義は、1955〜1958年の Louis Essen・Jack Parry の原子時計、William Markowitz の天文観測、WWV の無線時報信号を結びつけた較正作業に由来する

NTPから始まる時刻の階層

  • コンピューターがどこから時刻を取得しているのかに対するいちばん短い答えは NTP である
  • ただしNTPサーバーも自力で時刻を作っているわけではなく、出所をたどると複数の階層が連なっている
  • NTPは stratum 構造で時刻を伝達する
    • stratum 3 NTPサーバーは stratum 2 NTPサーバーから時刻を受け取る
    • stratum 2 NTPサーバーは stratum 1 NTPサーバーを基準にする
    • stratum 1 NTPサーバーは基準時計(reference clock)から直接時刻を取得する
  • 基準時計は英国の MSF、ドイツの DCF77 のような無線信号であることもあるが、多くの場合は GPS 受信機である可能性が高い

GPS時刻と米国海軍天文台

  • GPS時刻の出所をたどると、コロラド州の Schriever Space Force Base に行き着く
  • Schriever には複数の極秘衛星や関連任務があり、近づいてよい写真を撮るのは難しい
  • 現地には US Naval Observatory Alternate Master Clock がある
  • この補助マスタークロックは、ワシントンDCの US Naval Observatory から時刻を受け取っている

USNOが時刻を合わせる三つの基盤

  • 原子時計

    • US Naval Observatory の第一の基盤は 多数の原子時計 である
    • ラックマウント型のセシウムビーム時計、水素メーザーが入った黒い箱、rubidium fountains が使われている
    • USNO は原子時計専用の建物があるほど多くの時計を保有している
    • Apple Maps で USNO キャンパス中央に大きな工事現場が見え、これは新しい時計棟であることが確認された
    • 時計精度の主な制約は温度・湿度のような 環境安定性 であり、新しい建物には強力な空調設備が備えられる予定である

  • 地球自転情報

    • 第二の基盤は、UTC が原子時計時刻と 地球自転時刻 のあいだの折衷であるという点にある
    • USNO はパリ天文台を拠点とする国際地球回転・基準系事業 IERS から関連情報を受け取っている
    • IERS は年に2回 Bulletin C を送り、6か月後にうるう秒があるかどうかを知らせる
    • うるう秒は UTC を地球自転に合わせるために追加または削除されうる
    • IERS Bulletin A は地球方向パラメータの精密情報を含む週次通知で、US Naval Observatory が配信している
    • GPS が高精度な位置を提供するには、衛星の下にある地球の向きを正確に把握する必要がある

  • 原子時計の検証

    • 第三の基盤は、USNO の原子時計が正しく動作しているかを確認するための情報である
    • この情報はパリの BIPM から来ており、BIPM は世界全体の標準UTCを維持している

BIPM、UTC、SI秒

  • BIPM は世界各国の時間研究所の時刻測定値を集めて 公式UTC を決定する
  • 定期的に発行される Circular T には、公式UTCと各国の時間研究所のUTCとの不一致情報が記されている
  • BIPM は国際単位系 SI の維持責任も負っている
  • SI は CGPM が定義しており、CGPM は1875年のメートル条約で設立された国際条約機関である
  • UTC はセシウム原子の量子測定に基づくSI時間単位の実装である
  • 現在の秒の定義に含まれる約 9.2GHz という数値は、初期のセシウム原子時計の較正に由来する

セシウム原子時計と天文学的な秒のつながり

  • 1955年に Louis Essen と Jack Parry が最初のセシウム原子時計を作り、現在の秒の定義はこの時計の較正から生まれた
  • 原子時計以前の秒は天文学に基づいていたため、Essen と Parry は原子時計が従来の時刻標準に比べてどれだけ速く刻むかを突き止める必要があった
  • この接続作業には US Naval Observatory の天文学者たちが参加した
    • William Markowitz は空を観測して時刻を測定した
    • Louis Essen は原子時計を見て時刻を測定した
    • 二つの測定を一致させるため、両者ともワシントンDCの National Bureau of Standards が送信した WWV の無線時報信号を聴いた
    • この作業は 1955〜1958年 の3年間にわたって行われた
  • Markowitz が測定していたのは ephemeris second だった
    • 1952年、国際天文学連合は時間の定義を地球自転ではなく、太陽の周りを回る地球の軌道に基づくものへ変更した
    • 1930年代には、地球自転が完全に一定ではなく、少しずつ遅くなったり速くなったりすることが発見された
    • 時計が地球自転よりも高精度になるにつれ、ephemeris second がより精密な新しい時刻標準となった
  • ephemeris second は太陽系の数学モデルである 天体暦(ephemeris) に基づいている
    • 標準的な天体暦は Simon Newcomb が1800年代後半に作成した
    • Newcomb は膨大な歴史的天文データを収集して数学モデルを構築した
    • このモデルは1980年代半ばまで標準として維持された
  • Simon Newcomb も US Naval Observatory と US nautical almanac office で働いていた
  • さらに古い時代には、星が空を横切る様子を観測して時計を合わせる方法のほうがより直接的だった
  • コンピューター時刻の出所は Royal Greenwich Observatory ではない

関連記事

1件のコメント

 
GN⁺ 2023-10-06
Hacker News のコメント

  • 時刻の維持に関連して、NIST Randomness Beacon もある: https://csrc.nist.gov/projects/interoperable-randomness-beac...
    このプロトタイプは、60秒ごとに512ビットブロックとして完全なエントロピービット列を生成して公開し、各値にはシーケンス番号・タイムスタンプ・署名が付与され、さらに前の値のハッシュも含めることで値をチェーン状につないでいる。
    ここで「時刻をブロックチェーンに載せる」という冗談があったが、NIST はすでに似たようなことをしているとも言える。

    • これはブロックチェーンではなく、単一作者の Merkle DAG に近い。
      合意は不要で、単一の作者がいる Git リポジトリのようなもの。
    • これが何に使われるのか、例が気になる。
      公開された長い乱数文字列をチェーンに載せることが、ある出来事が特定時点より前には起きていなかったことを証明する用途以外に、なぜ有用なのかよく分からない。
    • なぜこれを P2P 乱数システムのルートとして使わないのか、ずっと不思議に思っていた。
      変わることのないいくつかの鍵を持つ信頼できる時刻ソースがあり、誰でも再送信できるなら、かなり有用そうだ。
      手動設定なしで最寄りのスマートフォンやコンピューターから時刻を受け取る、ゼロ設定の時計も可能になるかもしれない。

  • コンピューターが時刻を自動同期しないようにしておくと、時刻がどれほど速くドリフトするか見られるのは驚きだ。
    今のメインデスクトップは1.7秒進んでいるが、数週間は時計を更新していない可能性が高い。
    それでもこの程度ならひどいほうではなく、他のシステムはもっと大きくずれることがある。
    なぜ NTP で自動設定しないのかというと、ドリフト速度を見たいのかもしれないし、実行中のサービスをできるだけ減らしたいのかもしれないし、手前にある Ethernet スイッチがあまり点滅しないでほしいのかもしれないし、時計が大きくずれたときに何が壊れるのか思い出したいのかもしれない。
    結局の答えは「自分がそうしたいから」であり、多くのコンピューターの内部時計や水晶発振子はまったく精密ではない。

    • 水晶の誤差は通常 20ppm 程度。
      1週間なら20ppm基準で約12秒ほどずれる可能性がある。
      マザーボードにはおそらく、電源が抜けても時刻を維持するための CR2032 が入っているはず。
      水晶の例: https://www.digikey.com/en/products/filter/crystals/171?s=N4...
    • 詳しくは言いにくいが、ある IoT 製品では、NTP が失敗するとすべてのデバイスがゆっくり遅れていくようになっていた。
      NTP を直すと時刻が前にジャンプし、「同じ瞬間を二度生きる」代わりに認識される時刻に空白が生じるため、この設計は気に入っていた。
      そのため、速度計が意図的に少し高めに表示されるように、水晶もコンピューターが未来へ滑っていかないよう、わざと少し遅く作られているのだと思っていた。
    • 約40日前にミニ PC をホームサーバーとして設定したとき、Fedora Server がデフォルトで NTP 同期を構成しないことを知らなかった。
      2週間で30秒のドリフトが蓄積し、Prometheus が警告したが、最初は単一ノードにすべてを載せたせいで出た警告だと誤って推測していた。
      メトリクスを照会しているうちに、ドリフトのせいでエラーが出ているのを見て、サーバーとノート PC で date +'%s' の出力を比較したところ、差は30秒をはるかに超えていた。
    • Wikipedia によると、一般的な水晶 RTC の精度は ±100〜±20ppm、つまり1日あたり8.6〜1.7秒程度。
      温度補償 RTC IC なら 5ppm 未満も可能で、実用上は航海用クロノメーターの伝統的な用途である天文航法を行えるほど十分だ。
      2011年にはチップスケール原子時計が登場し、はるかに高価で消費電力も大きいが、50ppt 以内で時刻を維持する。

  • 興味深い解説だが、この形式は情報を伝えるにはあまりに不便。
    スライドを取り除いて一貫した段落の文章として書き直し、重要な画像だけを補助資料として入れ直したほうがよかったと思う。

    • 誰かがオフラインで発表したあと、オンラインでできることにはいくつかの段階がある。
      発表した事実を知らせる、録画を公開する、説明なしでスライドをPDFなどで公開する、スライドをHTMLページに配置して発表者が話したであろう内容を添える、そして最後に全体を段落形式の記事として書き直す、というもの。
      ここでは1〜4まではやっていて、5までやっていないと不満を言うのはかなり大きな追加作業を求めることになるので、責めにくい。そもそも発表を読める形で公開してくれただけでもありがたい。
      モバイルでは、特に初期バージョンは読みにくかったという点には同意するが、「注釈付き発表」という形式自体が悪いわけではない。
      たとえば https://idlewords.com/talks/ の https://idlewords.com/talks/superintelligence.htm、https://noidea.dog/talks の https://noidea.dog/impostor、https://simonwillison.net/tags/annotatedtalks/ の https://simonwillison.net/2022/Nov/26/productivity/ のような事例があり、CSSを少し調整して画像を右側に置くようにすれば、もっと読みやすくできる。
    • 読むべき文章より先に画像が出てくる配置が特に紛らわしかった。
      「ここにNTPパケットの図があります」の次に、机に座った男性の写真が出てくるような感じ。
    • 実際の発表動画を見るほうがずっとよい: https://ripe86.ripe.net/archives/video/1126/
    • こういう形式は初めて見たが、好奇心旺盛な人が特定のテーマのラビットホールにはまっていく過程にかなり似ている。
      気に入った。
    • 意識の流れのように読める、面白い記事だった。

  • 多くのデバイスで共通して使われるリソースである NTP Pool にも触れる価値がある。
    ボランティアが運営するNTPサーバー群で、特にオープンソース系のデバイスでよく選ばれる。
    Microsoft、Apple、Googleはそれぞれ独自の時刻サーバーを運用しているが、それ以外のほとんどにとってNTP Poolは優れたリソースだ: https://www.ntppool.org/en/

    • 以前、バグのある Snapchat iOSリリース のせいで、NTP Poolが事実上DDoSを受けたことを思い出す: https://community.ntppool.org/t/recent-ntp-pool-traffic-incr...
    • しばらくRIPE NCCのGPS同期PCIカードを使ってプールに参加していた。
      面白かったが、マシンルーム環境ではドームアンテナを接続し続けるのが難しかった。
      特殊ケーブルは嫌われるし、屋上へのアクセスはセキュリティと漏水の面で悩みの種だった。
      最近はルビジウム時計もかなり安い。
      今はRaspberry Piで自宅オフィスの窓の外のGPS可視性と可用性を測定する、Bert HubertのGPSドリフト／可用性プロジェクトに参加しているが、こちらのほうがずっと面白い。

  • 計測器や測定方法が、基準物質よりも精密で安定し、信頼できるようになる瞬間は興味深い。
    そして誰か、たいていは一個人が、ついにその事実を発見するか、場合によっては自らそう作り上げる。
    暦表秒は太陽系の数学モデルである暦表に基づいており、標準暦表は1800年代末にSimon Newcombが膨大な歴史的天文データを集めて作ったモデルで、1980年代半ばまで標準として維持された。
    1952年に国際天文学連合は、時間を地球の自転ではなく地球の太陽公転を基準に定義するよう変更した。1930年代に、地球の自転が完全には均一ではなく、少しずつ遅くなったり速くなったりすることが発見されたためだ。
    時計はもはや地球の自転より精密になっており、暦表秒がより精密な新しい時間標準となった。

    • 高校でこの内容を習った記憶があるが、それ以前は実際にどのような1秒の長さを使っていたのか気になる。
      地球の自転を基準にしていたなら、Newcombが集めた「膨大な歴史的天文データ」とはどのようなデータだったのだろうか。
      時間とともに変化する地球の自転速度だけを基準に、時間の長さをどうやって信頼できる形で捉え、保存できたのか疑問で、おそらく別の自然現象と比較したデータだったのだと思う。

  • Big Timeに過度に依存しないためには、コミュニティが維持し民主化された時刻追跡標準が必要だと思う。

    • 実際には、すでにほぼそういう構造なのでは？
      True Time™は世界中の研究所にある数十台の原子時計を事実上平均して決められているので、これ以上「コミュニティ維持」や「民主化」に近づくのは難しいと思う。
    • 記事とこのコメントを見て、根本的な時刻維持メカニズムへの組織的攻撃がどのような影響を及ぼすのか気になった。
      冗長性と合意形成はかなりあるように見えるが、どのシステムが失敗し、どのような時間軸で問題が起き、どう復旧するのか気になる。
    • 晴れた夜空と現代のスマートフォンカメラさえあれば、時計の較正も可能な気がする。
      秒単位の精度も突拍子もない期待ではなさそうだが、較正には非現実的に長い時間がかかるかもしれない。

  • DARPAは Robust Optical Clock Network (ROCkN) プログラムに資金提供している。
    このプログラムは、サイズ・重量・電力（SWaP）が小さく、GPS原子時計より精度とホールドオーバー性能に優れ、研究室の外でも使える光原子時計を作ることを目標としている。
    大手クラウドプロバイダーの多くは、GPSから時刻を取得しつつ、GPSがない場合でも正確な時刻を維持できるOpen Compute Time Card級の機器を配備している。
    https://www.darpa.mil/news-events/2022-01-20

  • Raspberry Pi が余っていて、自分で Stratum 1 NTP サーバーを運用したいなら、この記事があります: https://austinsnerdythings.com/2021/04/19/microsecond-accura...

    • NTP 用途には、以前のボードより Raspberry Pi 4 を使うほうがよいです
      旧型ボードでは Ethernet ポートが USB ハブの背後にあるため、ネットワークにミリ秒単位のパケットタイミングのジッターが生じ、マイクロ秒単位の NTP 精度は得にくくなります
      さらに楽しむなら、断熱箱に入れて CPU 負荷をかけ、暖かく保つことで、Raspberry Pi をオーブン制御水晶発振器のようにすることもできます: https://blog.ntpsec.org/2017/03/21/More_Heat.html
    • GPS から直接時刻を受け取るなら、それは Stratum 0 サーバーです
      Stratum 1 サーバーとは、Stratum 0 サーバーから時刻を受け取るサーバーを指します

  • スライドの大半は、GPS や原子時計のような 時刻測定の物理学を扱っています
    それ自体は興味深いものですが、自分のコンピューターが現在時刻をどう取得しているのかを理解するには、「家庭用コンピューターはリモート時刻サーバーから送られたパケットの遅延時間をどう測定するのか？」のほうが、より関係の深い問いです
    複数の往復時間の長さを測って平均を遅延時間とみなすのか、特定の往復中に突然輻輳が起きたらどうなるのか、といった疑問のほうが、物理的な問いよりも不思議に感じられます

  • どの 時刻ソースを使うかには注意が必要です
    10〜15年ほど前、私たちのサーバーの1台が tick.usno.navy.mil と tock.usno.navy.mil を使うよう設定されていたのですが、Navy が配信する時刻に「問題」がありました
    一晩のうちに複数のライセンスサーバーが認証できなくなり、システムに接続できなくなりました
    SSH も数分以内の正確な時刻を必要とすると理解していたのですが、同じ建物の別オフィスからローカルにログインして時刻の不一致を確認し、時刻サーバーと同期方法を変更して解決しました

    • いくつか誤って記憶しているようです
      SSH は、ごく短命の SSH 証明書を使う場合でない限り、時刻をまったく気にしません