要約

  • 1985年、ネットワーク時刻に関する記録は三つに分かれていた。RFC 958はNTPメッセージ、RFC 956は時計を選ぶアルゴリズム、RFC 957は実験を扱う。
  • 結果はリンクと条件に依存した。ミリ秒級の測定には多くのサンプルが必要であり、インターネット上の全時計への精度保証ではない。

共有する時刻を支える階層

時刻のずれは一台の時計の問題にとどまらない。上流の基準やゲートウェイ、そこから先の通信経路のどこで誤差が生じたか分からなければ、複数ホストの時計をそろえる運用自体が不確かになる。1985年のNTP文書はこの課題を一つの魔法のパケットに任せず、メッセージ形式、選択アルゴリズム、実験測定という別々の証拠に分けて記録した。

1985年9月のRFC 958は、NTPのデータ表現とメッセージ形式を定めた。パケットには時刻だけでなく、参照時計の種類、ローカル時計の精度、推定誤差、ドリフト率も含まれる。要求がクライアントを出た時刻、サーバーに届いた時刻、応答がサーバーを出た時刻、クライアントへ戻った時刻を四つのタイムスタンプで記録し、オフセットと往復遅延を見積もる。一方で、複数の時計からどれを選び、観測値をどうフィルターするかは規定せず、今後の課題として残した。

時計が食い違う原因は一つではない。機器やソフトウェア、電波受信、ネットワーク遅延、運用ミスが影響する。RFC 956は同期を統計的な推定問題として扱い、観測を比べ、外れ値を見つけ、最も信頼できる時刻を推定する。単一の読み取りで時計の良否は決められない。

試験対象のリンクには通常データも流れていた

RFC 957は実験の記録を担う。DCnetの時計設計と、ホスト、参照時計、複数種類のリンクを含む試験を記した。その一部は、通常のデータも運ぶ経路を通じて時計を同期する状況を扱っている。静かな実験室で時刻メッセージだけを交換するのではなく、時間通信と通常通信がネットワークを共有する影響を見ようとした。

1985年6月下旬から7月初めの試験系列は、六つのホスト、三つの参照時計、複数の通信リンクを含んだ。日程は意図的に、米国標準局の時刻放送にうるう秒が挿入される時期に合わせられた。電力網の周波数を参照にできるかも検討したが、周波数を観測することと、それをローカル時計の補正に用いることは区別されている。

報告はこれらをインターネット全体の単一スコアにまとめていない。ホストやリンクによって結果は異なる。結論は条件付きだ。試験されたARPANET経路では、十分な数のサンプルがあれば数ミリ秒程度の同期が可能だった。RFC 956も実験データについて約十ミリ秒級の結果を記し、サンプル数の重要性を強調している。これは測定結果であって、サービス保証ではない。

三つの文書が示す三種類の証拠

RFC 958は通信相手が何を交換するか、RFC 956はノイズを含む観測をどう解釈するか、RFC 957は特定の実装と試験条件で何が起きたかを示す。混同すれば、パケット形式をアルゴリズムと取り違えたり、実験を普遍的な動作の証明に変えたりしてしまう。

1988年のRFC 1059は後に、NTPをアーキテクチャ、プロトコル、同期アルゴリズムを含むものと説明し、RFC 958以降に大きく進化したと記した。この後年の統合は、1985年の記録が何を未確定のまま残したかを示す。ただし、各システムがいつ採用したかまでは証明しない。

歴史的成果は完璧な時計ではない。メッセージが時刻情報を運び、アルゴリズムが参照を比較し、実験が実際の経路で結果を測るという証拠の連鎖だった。古い精度の数値を引用する際は、経路、参照、サンプル数、稼働条件も添えたい。「パケットが時刻を報告した」と「ネットワークが時計を同期した」は同じ主張ではない。

出典