Network Time Protocol
NTPで使用される64ビットのタイムスタンプは、秒を表す32ビット部分と、秒未満の時間を表す32ビット部分で構成されている。秒未満の時間は、2秒(233ピコ秒)の理論的な分解能を持っている。秒を表す部分は32ビット符号なし整数であり、起点(エポック)としている1900年1月1日 0時0分0秒(UTC)からの経過秒数を表す。この値は、起点からから2-1秒、すなわち42億9496万7295秒(約136年)で桁あふれする。最初の桁あふれは2036年2月7日 6時28分15秒の次の秒に発生し、起点と認識されてNTPが誤動作すると予想されている。これを2036年問題という。UNIXにはこの問題が複数の箇所で今後顕在化するとみられるが(例: 2038年問題)、このNTPについても該当する。
RFC 4330には、最上位ビットが0の場合は時刻が2036年から2104年の間であるとみなして、2036年2月7日6時28分16秒(UTC)を起点として計算することで2036年問題を回避する方法が書かれている。
NTPv4では128ビットのタイムスタンプが導入されており、秒と秒未満にそれぞれ64ビットを割り当てている。秒を表す64ビットのうち、半分の32ビットは現行のNTPと同じであり、残りの32ビットは、桁あふれの回数を表すEra Number(時代番号)である。ミルズによれば、「秒未満の64ビット値は、光子が光速で電子を通過するのにかかる時間を解決するのに十分である。もう1つの64ビットの値は、宇宙が薄暗くなる(宇宙の終焉)までの時間を明確に表現するのに十分である。」
ネットギア製のルーターがウィスコンシン大学のNTPサーバを参照するようハードコードされていたため、負荷が極度に集中した。以下に問題の経緯を記す。
2003年5月、ウィスコンシン大学に対して平均毎秒4万パケットのNTPサービスへの接続が行われた。
これに対し大学側はNTP用に公開していたポートを閉じ、悪意あるアクセスは数時間のうちに収まるであろうと考えていた。しかしながら1か月後の2003年6月の時点において、大学側の予想に反するどころかさらに状況は悪化し平均毎秒25万パケットを記録。さらなる調査によって、多くの接続元が1秒毎に問い合わせを行っている事に不審を抱くこととなる。接続元となっている2つの大学に協力を要請。調査結果の中で双方ともにネットギア製のルーターを使用していた事が判明、型番もMR814であると特定された。
chronyは、Red Hatのディストリビューションにデフォルトで搭載されており、ubuntuのリポジトリでも利用可能である。chronyは、不安定でスリープモードになったり、インターネットに断続的に接続したりするような一般的なコンピュータを対象としている。また、より不安定な環境である仮想マシン用にも設計されている。リソース消費量(コスト)が少ないのが特徴で、NTPだけでなく、Precision Time Protocol(PTP)にも対応している。主なコンポーネントは、コンピュータの起動時に実行されるデーモンであるchronydと、その設定のためのコマンドラインインターフェースであるchronycの2つである。
chronycは非常に安全で、数件の事故があっただけだが、その利点は、不必要な複雑さを避けるためにゼロから書かれたコードの汎用性にある。
chronyはGNU General Public License version 2で利用可能である。1997年にRichard Curnowによって作成され、現在はMiroslav Lichvarによってメンテナンスされている。
NTPサーバを設定する際は、サーバのIPアドレスを直接指定するのではなく、ホスト名を用いて指定すべき、とされている(RFC4330による)。
LAN内部にクライアント台数がそれなりにある場合には、外部へのトラフィックおよび外部NTPサーバの負荷を最小限にするため、LAN内にNTPサーバとして稼動できる機器を用意し、この機器(内部NTPサーバ)をプロバイダなどの外部NTPサーバに接続し、各クライアントはこの内部NTPサーバに接続する設定を行うと良い。
ルーターやクライアントパソコンなどのネットワーク上の各機器では、前述のようなNTPサーバにアクセスして、機器内部の時計の時刻をNTPサーバの時刻に合わせることで内部時計の誤差が少なくなる。