Summary

  • 初期のNIST時刻サーバーは3,000秒ごとに電話サービスACTSを呼び出し、自分の時計を確かめた。
  • インターネットへの応答と時計の校正は別々の仕事だった。電話側の故障で、応答を続けるサーバーの時刻が不調になることもあった。

正確な時計のそばに、モデムがあった

時刻を配るコンピューターにも、定期連絡が必要だった。ほかの機械には堂々と時刻を伝えながら、自分は電話をかけて時計を確認する。初期のNISTのサービスには、そんな律儀な裏側がある。

Judah Levineが1993年のPTTI会議で紹介した最初のサーバーは、米国コロラド州ボルダーに置かれていた。Daytime、Time、NTPの三つの形式で、National Institute of Standards and Technologyが維持するUTC(NIST)の時刻を提供した。

発表論文には、初期の校正方法が記されている。Automated Computer Time Service、略してACTSへ3,000秒に一度電話をかける。その実験では、サーバーの時計とUTC(NIST)との差を約0.8ミリ秒RMSに保てたという。そこから利用者へ届く時刻には、ネットワークを通る際の不確かさが加わる。

Levineの示したクライアントソフトなら、利用者が自分で長距離電話をかけずに時刻を取得できた。電話で基準を確かめる仕事は、サーバー側に集まったのである。

二つの線に、二つの役目

2002年5月の運用報告は、2001年11月時点の構成を詳しく説明している。各サーバーにアナログモデムと専用電話回線があり、ボルダーのACTSを定期的に呼び出した。電話は発信専用で、着信には応じない。インターネットの要求はEthernetで受け付けた。

ソフトウェアにも分担があった。時刻コードを返す処理と、サーバー自身の時計を調整する処理は独立していた。校正の電話は通常数時間おきに、約15秒間。通話の合間も、発振器の動きをモデル化したソフトが時計を補正し続ける。

ボルダーのサーバーには、現地の基準から毎秒一回のパルスも直接届いた。一部の遠隔地ではルビジウムの装置を使い、短期の安定性を高め、電話がつながらない間を限られた時間だけ支えた。同じサービスの背後に、それぞれの設置条件があった。

黙っただけで2037年

この仕組みには、故障も二つの経路からやって来る。電話回線が切れても、インターネットへの応答は続けられる。報告書には回線の故障とACTS側の問題が記録されている。利用者の要求に答えた機械が、基準時刻との連絡を失っている場合があった。

部分的な故障では、サーバーは通常、異常を示す状態情報を送った。多くのクライアントはそれを確認して別のサーバーを選んだが、確認しないものもあった。古いTime形式には、そもそも状態情報を載せる場所がない。

NISTは応答をやめる方法も試した。すると多くのクライアントが、無応答を2037年の時刻として扱ったと報告している。苦情の手紙も届いた。間違った時刻を言わないよう黙った時計が、利用者を未来へ送ってしまった。

運用担当者が直せるのは、自分の側だけとは限らない問題だった。すでに利用者の機械へ入ったソフトが、応答や沈黙の意味を決めていた。故障の知らせは、相手が適切に扱って初めて役に立つ。

時刻を守る耐火金庫

2001年11月には14台が運用され、別に試験用の設備があった。NISTが全体を管理し、離れた設置先のスタッフがハードウェア修理を手伝う。メーカーの保守契約が部品と作業を担い、ソフトの変更は非公開のサーバーで先に試された。

ディスクの複製を記録したテープと、構成やソフトの版を記したノートは、耐火金庫に保管された。壊れた機械を元の状態へ戻すための資料である。精密な時刻を配るには、何を取り付け、何を動かしていたかという地味な記録も必要だった。

利用者が受け取るのは短い時刻情報だ。その短さを支える仕事には、電話、時計の補正、部品交換、記録の保管が含まれていた。ネットの時計は、家事のような仕事を抱えていたのである。