## The Clock Mini-HOWTO

Ron
Bean

    rbean@execpc.com

JF Project
日本語訳

    JF@linux.or.jp

v2.1, November 2000

コンピュータに正確な時間を設定して、時計が狂わないようにする方法。

## はじめに

### ほんとは何時なんだい？

PC マザーボード上のリアルタイムクロック (Real-Time-Clock, RTC) チップの 不正確さは有名です。たいてい早すぎたり遅すぎたりするので、毎日少しずつ 時計が狂っていきます 訳注：コンピュータのクロックがどの程度正確かを教えてくれる、通信情報研究所の ページ http://www2.crl.go.jp/pub/jst/index-J.htmlがあります。 。 しかし、Linux にはソフトウェア上でこれを修正する簡単な方法があります。 その方法を使えば、外部の時報ソースに頼らずとも時計を非常に正確に保つことが できます。ただ、その設定方法を知る人があまりいないのは、(おそらく) 以下のような理由があるからだと思われます。

- Linux の設定全般を解説した文書ではほとんどこれに触れられておらず、 (外部の時報ソースを利用する場合以外は) 自動的に設定されることもないので、 デフォルトでは利用されないこと。

- `man clock` とコマンドを打つと `clock (3)` が表示されますが、これには全然別の事柄が記載されていること。`man 8 clock` もしくは `man 8 hwclock` を試して ください (セクションを指定せずに man page を検索した場合、一般の ディストリビューションではセクションの若い方が先に表示されるようになって います。`/etc/man.config` で指定した順に検索する ディストリビューションもあります)。

- そもそも時間自体を気にしていない人が多いらしいこと。

- 時計の時間を気にするひとは、ネットワークタイムサーバ (netwok time server) や電波時計 (radio clock) といった外部の時報ソースにシステムクロックを同期 (sync) させている人が大半であること。この場合、RTC が正確かどうかは(ほとんど) 関係がなくなります。

この mini-HOWTO では、ローテクな方向からアプローチします (それだけで、 時計は非常に正確になります)。また、もっと洗練された方法で時間調整したい 人のために、各種の情報源も紹介しています。後者の場合、その手の文書の解説 はおおむねしっかりしているので、本書では詳解しません。

本書の前バージョンでは、古いシステムをいまも使っている人のために旧式の `clock (8)` プログラムについて詳しく説明していましたが、今回は そのセクションを省略しました。現在多くのディストリビューションが `clock (8)` にかえて `hwclock (8)` を採用 しており、`hwclock (8)` プログラムに関する文献の方がずっと 優れているからです。`clock (8)` の解説文が必要な場合は、著者に メールで知らせてください。ただ、その場合は、先ず `hwclock (8)` についての章を読んでからにしてください。

#### 注意

RTC やシステムクロックを修正するプログラムを実行するには "root" でログイン しなければなりません。この文書で述べるプログラムの大半は、root 権限が 必要です。普段からグラフィカルインターフェイスしか使っていない場合は、 基本的な UNIX のシェルコマンドをいくつか学ぶ必要があるかもしれません。

#### 注意

マシン上で複数の OS を使っている場合は、そのうちひとつだけで RTC の 設定を行い、他の OS との間で時間が食い違うことがないようにする必要があります。 ただ、年に 2 度の夏時間の調整については別です (詳しくは、 DST のセクションをご覧ください)。

デュアルブートシステムで主に Windows を使っているなら、Linux 版では なく、Windows 版のクロックソフトウェアについて調べたいと思うかもしれません。 その場合は、次の NTP ウェブサイトの説明をご覧ください。 http://www.eecis.udel.edu/~ntp/software.html。 本書での電波時計の説明の多くは、Windows 用ソフトウェアに関するものも 含まれています。

### ソフトウェアの入手先：著名なアーカイブ

本書ではソフトウェアをダウンロードできる場所としていくつかのサイトを 挙げましたが、CD-ROM 版が手に入らない場合は Linux システム全体をそこから ダウンロードすることもできます。 昔は、そのようなサイトは sunsite.unc.edu の ftp アーカイブと各国のそのミラーサイトであると相場が決まっていましたが、 現在 sunsite は http://metalab.unc.edu/linux/ と改名されています (訳注： 2001年10月現在では ibiblio http://www.ibiblio.org/pub/linux/ という名称に変更されています)。 ディストリビューションの中には独自のウェブサイトを持っているものも あり、そのなかにはこの文書で扱うソフトウェアが含まれている場合も あります。

最近では Linux を CD で入手する人がほとんどであり、そうした CD にはデフォルト でインストールされないような各種ソフトウェアもたいてい含まれているので、 自分では意識していなくとも本書で述べるプログラムが既に手元にある場合が 多いと思われます。

この mini-HOWTO の最新バージョンは、Linux Documentation Project のホーム ページにあります。LDP のホームページは、現在 http://www.linuxdoc.org/ です (上述した metalab サイトからも入手が可能です)。古いリンクを指定した 場合でも必ず現在のサイトに forward されるようになっていると思います。

すべての HOWTO 文書は SGML で記述されており、規格に基づいた変換プログラム を使って各種フォーマットに変換されています。たいていの人は HTML 形式で 読むと思われます。HTML 版は、 http://www.linuxdoc.org/HOWTO/mini/Clock.html です。 改訂履歴は SGML ソースにコメントとして記載しています。 大部分のディストリビューションでは、全 HOWTO 文書が `/usr/doc/HOWTO/` と `/usr/doc/HOWTO/mini/` にインストールされています。

### 謝辞

この mini-HOWTO は、1996年の初版以来、著者にメールを送ってくれた多くの 方々のおかげで大幅に改善されてきました。中には、質問を受け取ったはずなのに、 結局こちらがいろいろと教えていただいたことも何度かありました。 残念ながら、著者はまだそれらの方の氏名のリストを作成していません (次回の改訂では多分記載できると思います)。心当たりのある方は、ご自分の ことだとお分かりになると思います `:)`

## Linux はどのように時間を計っているのか

### 基本的な仕組み

Linux システムには 2 種類の時計があります。ひとつは、バッテリー駆動の リアルタイムクロック(RTC や CMOS クロックもしくは ハードウェアクロックとも呼ばれています)であり、これはシステムの電源が オフの時にも動いていますが、システムの稼働中は使われません。 もうひとつは、システムクロック (System Clock, カーネルクロックもしくは ソフトウェアクロックとも呼ばれます) であり、これはタイマ割り込みに基づく ソフトウェア・カウンタ(software counter)です。 システムクロックは システムの稼働中以外には存在しないので、起動時に RTC (もしくは それ以外の外部時計) によって初期化される必要があります。`ntpd` の付属文書で「クロック」を参照するという場合、RTC ではなくシステム クロックの参照を意味しています。

それら 2 種類の時計のズレ具合は異なっているので、両者は徐々に食い違っていき、 双方ともだんだんと実際の正確な時間から離れていきます。これらを正確に 保つ上で最も簡単な方法は、時間がズレる割合を計算してソフトウェア上で それを修正することです。RTC はシステムの稼働していない時だけ使用されるもの なので、RTC の修正は、起動時に時刻を読み込む際に `clock(8)` か `hwclock(8)` を使って行います。システムクロックの 修正は、タイマ割り込みによりシステム時間が進む際に `adjtimex(8)` を使ってズレを修正することにより実施します。

`adjtimex(8)` の代わりに `cron` を使って `clock(8)` か `hwclock(8)` を 定期的に実行し、システムクロックを(正確に調整した)RTC に同期させる という方法もないわけではありません。これは `clock(8)` のマニュアルページで推奨されていますし、ある程度頻繁に同期させることで 両者の時間のズレを小さくしてシステムクロックの時刻が大幅に「ジャンプ」する ことがなければ問題なく機能しますが、`adjtimex(8)` を使って調整した方がエレガントです。アプリケーションのなかには、 時間調整で時計を遡らせた場合にはエラーになるものがあるかもしれません。

ntpd to read the time periodically from a network time server or radio clock, and continuously adjust the rate of the system clock so that the times always match, without causing sudden &dquot;jumps&dquot; in the system time. If you always have a network connection at boot time, you can ignore the RTC completely and use `ntpdate` (which comes with the `ntpd` package) to initialize the system clock from a time server-- either a local server on a LAN, or a remote server on the internet. But if you sometimes don't have a network connection, or if you need the time to be accurate during the boot sequence before the network is active, then you need to maintain the time in the RTC as well. ]]> 時間調整の方法としては、他にも `ntpd` というプログラムを 使ってネットワークタイムサーバや電波時計から定期的に時間を読み込んで 継続的にシステムクロックの誤差を調整することで、システムクロックの時刻の大幅な 「ジャンプ」を避ける方法もあります。もし起動時に必ずネットワークコネクションを 張ることが出来るなら、RTC を完全に無視し、`ntpdate` (これは `ntpd` パッケージに付属しています) を使って LAN 内のローカルマシンやインターネット上のリモートマシンにあるタイム サーバによりシステムクロックを初期化することもできます。しかし、もし 必ずしもネットワークコネクションを張れないときがある場合や、起動中に 正確な時間を取得した後にネットワークに繋がなければならない場合は、 RTC の時間も調整しておく必要があります。

### コンフリクトの可能性

`ntpd` のようなプログラムを使っているなら、RTC を (調整済みの)システムクロックに同期させようと思うかもしれません。 しかし、これはシステムが数分以上に渡って遮断される可能性がある場合には 予想通りに上手くはいきません。起動時に RTC を調整するプログラム と干渉してしまうからです。

システムが土日なしで 24 時間稼働し、電源が遮断された場合でもすぐに再起動する ようになっているなら、システムクロック時間に基づいて再起動直前に RTC を 設定することは可能です。その際は RTC にはリブート中の経過時間の範囲内でしか 誤差が生じないので、RTC のズレ具合を知る必要もなくなります。

もちろんシステムには予想外の障害が付きものです。そこで、システムクロックが 何らかのプログラムによって正確に調整されている場合、カーネルのバージョンに よっては RTC を 11 分ごとにシステムクロックに同期させるものがあります。通常 11 分間のうちに RTC がシステムクロックと大きく食い違うことはありませんが、 システムが長時間ダウンして RTC 時間が大きくズレた場合は問題が生じます。 なぜなら RTC の誤差を調整するプログラムは、自分が RTC を最後にリセットした 時刻を正確に記憶している必要があるのですが、カーネルには そのような情報は記録されていないからです。

UNIX の伝統を重んじる人の中には、Linux システムはもともと 24 時間連続稼働 させるものなのだと思っている方もいることでしょう。しかし、デュアルブート で時々は別の OS を実行しているユーザもいますし、ラップトップで Linux を使っているユーザは電源を落とすことで使用中以外の時間でのバッテリーの 消耗を防いだりもしています。それ以外にも、単に使っていないマシンを 長時間実行させっ放しにするのを好まない人もいます (むろん、電源を入れた ままにする方が良いという議論は充分承知はしていますが)。そのような場合、 11 分ごとに同期を行う機能は非常に不都合な機能ということになります。

この(場合によっては不都合な)機能は、カーネルのバージョンが異なると 振る舞いも異なるようです (おそらく `xntpd` や `ntpd` のバージョンが異なる場合も、 振る舞いが変わるようです)。それゆえ、もし `ntpd` と `hwclock` の両方を 実行しているなら、予めテストを行って、その機能が実際にどういう振る舞いを するのか確認する必要があるでしょう。もしカーネルが RTC をリセットする のを止めさせることができない場合は、RTC に対する時間調整を一切行わない ようにする必要があるでしょう。

こうしたことを制御しているのは、カーネル内の `/usr/src/linux-2.0.34/arch/i386/kernel/time.c` です (パス中のバージョン番号は、お手持ちのカーネルのバージョン番号に置き換えて ください)。変数 `time_status` が `TIME_OK` に設定されると、カーネルはシステム時間を 11 分ごとに RTC に書き込もうと し、それ以外の値だと RTC には干渉しません。(例えば、`ntpd` や `timed` を使って) `adjtimex(2)` を 呼び出すことで、これをオンにすることができます。`settimeofday (2)` を呼べば、`time_status` を `TIME_UNSYNC` に設定することができます。これは、カーネルに RTC の調整をしないよう指示するものです。この辺りのことを詳しく説明した 文書を著者は知りません。

カーネルのバージョンによっては、CPU への電源供給を遮断してバッテリー を長持ちさせる sleep 機能に問題があるものがあるという報告を受けています。 最良の解決策は、カーネルを常に最新の状態に更新してゆくことであり、 カーネルの管理者に問題を報告するようにすることです。

RTC の狂い方が妙な場合は、ハードウェア上の問題かもしれません。RTC チップにはリチウム電池が内蔵されていますが、この電池が切れたのかも しれません。また、マザーボードによっては外部バッテリーを使えるように 設計されたものもあります(ジャンパの設定を確認してください)。 CMOS RAM も RTC と同じ電池で動いているのですが、時計の方が 電力の消費が激しいのでたいてい先に動かなくなります。システム クロックの表示がおかしい場合は、割り込みに問題があるかもしれません。

### RTC にはローカルタイムか UTC のどちらを使うべきか？ DST って何？

conversion between UTC and local time. The translation to local time is done by library functions that are linked into the application programs. ]]> Linux のシステムクロックが実際にカウントしているのは、1970年1月1日 からの経過秒数であり、時刻は必ず協定世界時 (UTC, Coodinated Universal Time) を使います (UTC は GMT (Greenwich Mean Time) とほぼ同義です。 両者は技術的には別物ですが非常に似通っているので、一般のユーザは 同じ意味で使うことが多いようです)。UTC は、夏時間 (DST, Daylight Saving Time) が必要な場合でも変更されることはありません。変わるのは、UTC とローカルタイム との間での変換方法だけです。ローカルタイムへの変換は、アプリケーション プログラムにリンクされたライブラリ関数によって実行されます。 (訳注：DST (いわゆるサマータイム)については、 いまのところ日本では関係ありません。)

これは、結果的に二つの意味を持ちます。まず第一に、アプリケーションが ローカルタイム知る必要がある場合は、DST が有効であるか否かに関わらず、 同時にユーザのタイムゾーンも知る必要があるということです (タイムゾーン については、次章を参考にしてください)。第二に、DST が問題になる場合でも、 UTC 自体に変更はないので、カーネルはシステムクロックや RTC を変更する必要 がないということです。それゆえ Linux しか走らせないマシンの場合、 RTC はローカルタイムではなく UTC に設定すべきです。

しかしながら、RTC がローカルタイムを表示していることを前提にした OS を 同居させて、デュアルブートシステムにしている人は多いと思います。その場合、 `hwclock` は RTC がローカルタイムか UTC であるか を知る必要があり、さらにその時刻を 1970年1月1日 (UTC) からの経過秒数へと 変換する必要があります。ただ、これは RTC に対する夏時間調整までは行わない ことから、夏時間への変更は Linux 以外の OS 側で実行する必要があります (これは RTC の時間を変更する際は単一プログラムを使い、重複した変更を行わない というルールの例外に当たります)。

残念ながら、RTC や CMOS RAM にはローカルタイムの表示に関して標準時間か DST なのかを区別するためのフラグがないので、OS は、おのおの他の OS からは分からない 場所にその情報を保存しています。つまり、夏時間の始期や終期の前後に Linux 以外の OS を起動して時間調整していない場合であっても、 `hwclock` は、RTC が いつも正しいローカルタイムを表示していると仮定しなければならないわけです。

夏時間調整の始期や終期の前後に Linux が動いていた場合、システムクロック自体は 影響を受けないわけですし、アプリケーションも正しい時刻変換をするでしょう。 しかし、何らかの理由で Linux を再起動しなければいけない場合、 システムクロックは RTC 時間に合わせて設定されます。その場合、 システムクロックは他の OS (通常は Windows) が実行されるまで 時刻が 1 時間狂ってしまいます。

これに対処する方法はないのですが、Linux はめったなことではクラッシュ しないので、デュアルブートシステムでリブートをかけるのは たいてい Linux から他の OS に切り替えるためです。しかし、 もし長時間コンピュータを使わないときに電源を切るタイプの人なら、つまり 夏時間調整の変更があっても他の OS を使う機会がなかったなら、 他の OS を走らせるまで RTC は一時間狂うことになるのを忘れないで ください。

解説書のなかには、RTC を UTC に設定することで Linux が DST を上手く 扱えるようになると説明しているものがあります。これは全くの間違い ではないですが、不正確です。リブートをしない限り、(RTC のバッテリー が切れていた場合でも、) RTC がどちらの時間を表示しているかは問題 になりません。Linux は、リブートがかかるまではいずれかの方法で 正しい時間を表示しているわけです。理論的には、もし一年に一回しか リブートしないなら(これは、Linux の場合、特に珍しいことでは ありません)、DST が問題になる場合でもシステムクロックはずっと 正確な時間を伝えているので、RTC が狂ったとしても何ヶ月も気付かない でしょう。しかし、いつリブートをするかということは予め予測が付かない ので、ローカルタイムを必要とする OS を使っていない場合は、 RTC を UTC に設定した方がいいでしょう。

Dallas Semiconductor の RTC チップ (これは、Motorola チップの代わりに IBM AT 機やその互換機に搭載されるようになったチップです) は、実際に チップ自体に UTC を DST に変換する能力が備わっていますが、変更すべき 日付があらかじめハード的に固定されていてそれをソフト的に変えることが できないので、この機能は使われていません。最新のバージョン更新が 2000年4月の第一日曜日と 10月の最終日曜日に実施されましたが、それ 以前のバージョンのチップでは、それぞれ異なった日時が使われています。 (また、これは(合衆国と)違う日付を使っている国では、明らかに機能しません。) さらに、RTC は (単体のチップではなく) マザーボードのチップセットの 中に組み込まれている場合も多くなっているので、それらすべてがこの 能力を持っているかどうか著者には分かりません。

### タイムゾーンの設定について

おそらく Linux インストールの際に、読者はタイムゾーンを正しく 設定していると思います。しかし、もし何らかの理由でそれを 変更しなければならない場合、もしくは DST に関する自国の法律が 変更された場合(こういう法律変更が頻繁に起こる国もあります)、 タイムゾーンを変更する方法を知る必要が生じるでしょう。 システム時間がきっかり数時間ずれているようなときは、 タイムゾーン (もしくは、DST) の設定に問題があります。

タイムゾーンや DST の情報は、`/usr/share/zoneinfo` (もしくは `/usr/lib/zoneinfo`) に保存されて います。ローカルなタイムゾーンは、`/etc/localtime` から上記のファイル群のひとつにシンボリックリンクを張ることで決定 されています。タイムゾーンを変更するには、そのリンクを張り替え ましょう。もし DST の日付が変わらない場合は、そのファイルを編集する 必要があります。

また、環境変数 `TZ` を使って現在のタイムゾーンを変更することも できます。これは異なるタイムゾーンにある遠隔マシンにログインしている 場合には、便利な方法です。詳しくは、`tzset` と `tzfile` のマニュアルページをご覧ください。

これについては、次のサイトで分かり易く説明されています。 http://www.linuxsa.org.au/tips/time.html

### どの程度の精度が必要か

ミリ秒単位での正確さが不要なら、`hwclock(8)` と `adjtimex(8)` だけでおそらく充分です。タイムサーバや電波時計 等に夢中になったとしても無理はありませんが、著者は古い `clock(8)` プログラムだけでここ数年すばらしい結果を得ています。 他方、LAN 上に複数のマシンがある場合は、互いに時計を自動的に同期させる ことができれば便利です(あるいは、それが不可欠な場合もあります)。それ以外 にも、特に必要がなくても使ってみて面白いツール類もあります。

Linux だけしか走らせないマシンならば、RTC を UTC (もしくは GMT) に 設定しましょう。RTC をローカルタイムに設定する必要のあるデュアルブート システムの場合は、注意すべき点があります。もし夏時間の変更前後に Linux をリブートしなければならないときは、時計が暫定的に一時間ずれてしまうことが あるということです。その状態は、もう一つの OS を起動するまで続くことになり ます。3 つ以上の OS が載っている場合は、そのうちひとつの OS だけで DST を 調整するよう気を付けてください。

## ソフトウェア

### clock(8) と hwclock(8)

どのようなディストリビューションでも古い `clock(8)` か 新しい `hwclock(8)` のどちらかはインストールされます ( 時間の調整は自分でする必要があります)。`adjtimex(8)` も インストールされるか、オプションとして CD に同梱されているでしょう (`adjtimex` は通常の Linux アーカイブサイトからダウンロード することもできます)。ディストリビューションによっては X Window 上で グラフィカルにクロックを設定するプログラムを含んでいたりしますが、 それらはあくまでインタラクティブな使い方をするようになっているので (自動設定ができないので)、`clock(8)` や `hwclock(8)` もインストールされ 初期化スクリプトで自動設定が出来るようになっています。

`clock` の場合、時間調整のための数値は手動で計算 しなければなりません。他方 `hwclock` の場合、そのコマンド を使って RTC をリセットするたびごとに調整率を自動で計算してくれます (両方を 交互に使って RTC を設定すると時間調整が狂ってしまうので、調整の際は 必ずどちらか一方を使うようにしてください)。もし `clock` しか入っていない古いシステムを使っていてアップグレードしたい場合は、 `hwclock` は `util-linux` パッケージのバージョン 2.7 以降に含まれています。詳しくはマニュアル ページをご覧ください。

`hwclock(8)` のマニュアルページは、下位互換性を保つために `clock` のコマンド名で呼び出す設定になっていることがある ので、両方のコマンド名を試してください。`hwclock` は `clock` 用のコマンドにも反応はしますが、その場合処理結果は `clock` の時とは異なるかもしれません。特に `hwclock -a` は、`clock -a` とはかなり異なって います。もし `hwclock` にアップグレードしているなら、 初期化スクリプト内で `clock` 用コマンドを使っている 部分はすべて `hwclock` のネイティブコマンドに差し替える ことをおすすめします。

初期化スクリプトはディストリビューションごとに異なるので、多少調べないと クロックを設定している場所が見つからないかもしれません。典型的な場所は `/etc/rc.local` や `/etc/rc.d/rc.sysinit` 、`/etc/rc.d/boot` などです。

RTC の時間調整用の数値は、`/etc/adjtime` に保存されて います。Red Hat の場合 `etc/sysconfig/clock` に スクリプトがあり、そのスクリプトで `hwclock` のオプション を制御しています。

ntpdate program that comes with `ntpd`, and there's a javaclock at . ]]> クロックの設定で時計の規則的なズレを調整する場合は、電話での時報が 正確ではない場合があり得ることを念頭に置いてください (訳注：まあ、 アメリカでの話だと思います)。短波ラジオや GPS レシーバを持っていないときは、(303)499-7111 に電話をして、 WWV から時報を聞くこともできます(これは、コロラドのボルダーへの 長距離電話になります)。3 分で自動的に切れますが、クロックの設定には 充分です。USNO やカナダの CHU も時報サービスをしていますが、著者は WWV のほうがいいと思います。時間のアナウンスと時報音の間隔が長い からです。他にも `ntpd` 付属の `ntpdate` を使ってネットワークタイムサーバから時刻を得ることもできますし、 www.time.gov には javaclock もあります。

どれを使った場合でも設定するのはシステムクロックであり、RTC では ありません(`date` コマンドのマニュアルページを 見て、どういうフォーマットを使うのか確認してください)。そして、 `hwclock` を使用して RTC を設定し、規則的なズレの 割合を計算します。手動でやる場合、1 秒か 2 秒以内の誤差に設定して、 一週間後におよそのズレの率を確認するようにしてください。そして `adjtimex` を実行し、システムクロックを調整してください。

### Adjtimex(8)

`adjtimex` コマンドは、カーネルの時間変数の調整が できるので、それによってシステムクロックのスピードを変更するようになって います(実行の際には root でログインする必要があります)。`hwclock` は設計が秀逸であり、システムクロックと RTC の時刻を 比較する際に `/etc/adjtime` に保存された、`clock` でも `hwclock` でも使える同一の調整数値を 使うようになっています。それゆえ RTC の規則的ズレを直してしまえば、 システムクロックを調整するのも非常に簡単です。一旦クロックが正しい スピードで動くように出来たなら、初期化スクリプトに設定行を追加して 起動時にカーネル変数を適切に設定することができます。`adjtimex` は `clock` でも `hwclock` でも使えるように設計されているので、前述した「11 分ごと」のバグも 回避できるようになっています。

`adjtimex` のインストールが済んだら、設定に関する詳しい情報 を得るには `man 8 adjtimex` とタイプするか (設定以外の情報に関する `adjtimex` のマニュアル ページもあります)、`/usr/doc/adjtimex-1.3/README` の `README` ファイルを読むかしてください (ディレクトリパス上のバージョン番号は、`adjtimex` の 最新バージョンの番号となります)。

### xntpd と ntpd - ネットワークタイムプロトコル

`xntpd` (NTPv3) は、`ntpd` (NTPv4) に置き換わりました。古いバージョンは現在メンテナンスの対象外となっています。

`ntpd` は、ネットワーク越しに時計を同期させる標準的な プログラムであり、 プログラムには接続可能なパブリックタイムサーバのリストが付属しています。 設定については本書で述べているようなプログラムよりもやや複雑かもしれま せんが、この種の事柄に興味があるならまずざっと眺めてみることをおすすめ します。

`ntpd` に関する情報は NTP のウェブサイトである http://www.eecis.udel.edu/~ntp/ に集約されています。またここには、時間に関連する様々な事柄 (他の OS 用のソフトウェアも含む) へのリンクが掲載されています。 ディストリビューションによっては `ntpd` が CD に 収められている場合もあります。パブリックタイムサーバのリストは、 http://www.eecis.udel.edu/~mills/ntp/clock2.html をご覧ください。

`ntpd` の比較的新しい機能に、「バーストモード(burst mode)」 があります。 これはダイアルアップで時々しかインターネットに接続しないマシン用に 設計された機能です。

`ntpd` には、電波時計用ドライバも数多く含まれて います (ただ、なかにはあまり性能の良くないのもありますが)。電波時計 の大部分は商用として作成されていて、数千ドルの値段が付いたりしますが、 それにかわる安価な手段も存在します (これについては後ほど解説します)。 以前はほとんどが WWV や WWVB レシーバでしたが、現在では大部分が GPS レシーバとなっています。NIST のウェブサイトには PDF ファイル形式での 電波時計の製造元一覧表があります。 http://www.boulder.nist.gov/timefreq/links.htm (ページの末尾です)。 また NTP ウェブサイトにも電波時計の製造会社へのリンクが多数掲載 されています。 http://www.eecis.udel.edu/~ntp/hardware.htm および http://www.eecis.udel.edu/~mills/ntp/refclock.htm。 どちらのリストも、随時更新されたりされなかったりのようです :-) `ntpd` のドライバは、 http://www.eecis.udel.edu/~ntp/ntp_spool/html/refclock.htm にあります。

`ntpd` には、ダイアルアップ用のタイムサービスについての ドライバも含まれています。これらはすべて長距離電話を使うので、 プログラムを使う前に電話料金がどれくらいになるか計算するのを忘れない でください。

### chrony プログラム

`xntpd` はもともとネットワークタイムサーバか電波時計 に常時接続できるマシン用に作られていました。理論的には時々しか接続しない マシンでも使えるのですが、Richard Curnow は思い通りの方法で `xntpd` を動かすことができなかったため、`chrony` という プログラムを作成し、ISP にダイアルアップで接続するときしかネットワークに アクセスしないユーザ向けに別の手段を提供してくれました (これは `ntpd` が新機能である burst mode で解決しようとしたのと 同じ問題です)。`chrony` の現在のバージョンには、 長時間電源をオフにするマシン用に RTC の規則的ズレを解消する機能も 含まれています。

詳しい情報は Richard Curnow のウェブサイト http://www.rrbcurnow.freeuk.com/chrony や http://go.to/chrony をご覧下さい。`chrony` には二つのメーリングリスト があり、ひとつはアナウンス用、もうひとつはユーザによる議論の場と なっています。詳しくは <hrony-users-subscribe@egroups.com> か <chrony-announce-subscribe@egroups.com> に メールを送信してください。

`chrony` は通常ソースコードのみの配布となっていますが、 Debian では、unstable のなかにバイナリ版が含まれています。 ソースファイルについても、著名な Linux アーカイブサイトで入手できます。

### clockspeed プログラム

それ以外の選択肢として、DJ Bernstein による `clockspeed` というプログラムがあります。これはネットワークタイムサーバから時間を 取得して、3 秒ごとにシステムクロックを再設定するという単純な方法を 使うものです。また LAN 上にあるいくつかのマシンを同期させるために 使うこともできます。

彼のウェブサイト http://Cr.yp.to/clockspeed.html はときどきトラブルが あるようです。もし DNS エラーが出るようなら、再度翌日にアクセス してみてください。この部分については詳しい情報が入り次第、 更新します。

## 電波時計

### CHU と 「Gadget Box」

CHU とは、オタワ近郊にあるカナダ短波時報局 (Canadian shortwave time station) のことであり、合衆国の WWV に類似した組織ですが、両者にはひとつだけ重要な 違いがあります。CHU は英語とフランス語で時報を提供するだけでなく、 古い "Bell 103" (300 baud) モデムトーンを使って一分間隔で時報を放送 しているという点です。このトーンはデコードが非常に容易であるため、 Bill Rossi はモデム(デコーダ)を使うまでもなく、短波ラジオとサウンドカードで 解析できることを発見しました。CHU からの信号を受信できるなら、これは 最も安上がりな電波時計として使えます。短波の受信状況は一日のうちに 何度か変化しますが、Bill によると、日に二回 (朝と夕方) 周波数を変えれば ほぼ 24 時間受信できるそうです。CHU の放送は 3.33, 7.335, および 14.670 MHz です。

詳細は Bill Rossi のウェブサイト http://www.rossi.com/chu/ をご覧ください。ソースファイルは著名なアーカイブサイトからも入手できます。 CHU の時報サービスについては、 http://www.nrc.ca/inms/time/ctse.html を見て下さい。

「Gadget Box」というプランが NTP ウェブサイトにあります。これは安価な 300 baud のモデムと適当な短波ラジオを使って CHU の時報をデコードするという ものです http://www.eecis.udel.edu/~ntp/ntp_spool/html/gadget.htm。 このプランでは専用の両面プリント基盤に関する PostScript 図を掲載しています が、基盤自体は自分で作らなければなりません (もしくは、作ってくれる人を 探す必要があります)。

`ntpd` には CHU レシーバ用のドライバ (type 7) が含まれて います。これは「Gadget Box」のようなモデムを使うか、もしくは Sun SPARCstation (あるいはその互換オーディオドライバを持ったマシン) のマイク 入力に直接音声を入力することで動くようになっています。

### WWV と「Most Accurate Clock」

Heathkit 社の「Most Accurate Clock」というのを聞いたことがある方もいる でしょう。これは WWV の時報を受信してデコードし、オプションのシリアルポート を使ってコンピュータに接続するというものです。Heathkit は随分まえに このキットの販売を止めてしまいましたが、1995年まではこの時計の完成品版の 販売を続けていました (現在は販売していません)。(時計以外の製品を 含めた) Heathkit 社へのノスタルジアを書いたページが http://www.heathkit-museum.com にあります。Heathkit 社自体は 今も健在であり、学習用の教材を販売しています。詳しくは http://www.heathkit.com をご覧ください。

Dave Mills によると、Heathkit 社の「Most Accurate Clock」に関する特許は もうすぐ期限切れになるので、もしかするとそのクローンをシングルチップ IC として売り出す会社が出てくるかもしれないそうです。

NTP ウェブサイトには DSP プログラム (およびそれを解説した PDF ファイル) があります http://www.eecis.udel.edu/~mills/resource.htm。 これは短波ラジオと TAPR/AMSAT DSP-93 という (現在では販売していない) DSP キットを使って WWV 時報をデコードするものです。このキットは Texas Instruments の TMS320C25 DSP チップをベースにしたものです。TAPR のウェブサイト http://www.tapr.org には 自社開発の DSP プログラムに関する情報が豊富にあります。

`ntpd` パッケージには IRIG-B と IRIG-E タイムコードの ドライバ (type 6) も含まれています。 これは Sun SPARCstation の `/dev/audio` を利用するものですが、それ以外のシステムにも移植が可能だそうです。 WWV では IRIG-H タイムコードが使われています。

WWV は NIST により運営されており、ウェブサイトは http://www.boulder.nist.gov/timefreq/index.html です。 このサイトには "Special Publication 432" という文書があり、これには 時間と周波数についての記述があります。 http://www.boulder.nist.gov/timefreq/pubs/sp432/sp432.htm. WWV は 2.5, 5, 10, 15, 20 MHz で放送しています。

### GPS と「Totally Accurate Clock」

GPS 信号には正確な時間も含まれていて、GPS レシーバのなかにはシリアル ポートを備えたものがあります。ntpd には各種 GPS レシーバ用のドライバが 同梱されています。1PPS 機能 ("One Pulse Per Second", これはかなり高精度 を要する場合に使われるものです) は、通常特別なインターフェイスを使って コンピュータに繋ぐ必要があります。

TAPR (Tuscon Amateur Packet Radio) には TAC-2 ("Totally Accurate Clock" の 略) というインターフェイス用のキットがあります。これはシリアルポートに 差し込んで GPS レシーバと繋ぐためのインターフェイスであり、1PPS の出力を もつ GPS レシーバならどんなものでも使えます。またこれには回路基盤に 直接載せることができるベアボードモデル (bare board model) もあります。 詳しくは http://www.tapr.org/ のウェブサイトをご覧ください。(1999年6月時点での) 値段は、GPS レシーバ抜きで 140 ドル前後です。このキットには筐体や回路基盤 取り付け用の部品は含まれていません。

(別の章で述べた) CHU 「Gadget Box」 も 1PPS 信号のインターフェイスとして 使うことができます。NTP ウェブサイトにはこれに関する説明が記載されて います http://www.eecis.udel.edu/~ntp/ntp_spool/html/pps.htm。

### 長波タイムシグナル： DCF77, MSF(Rugby), WWVB

長波放送局では、キャリアのオン・オフ切り替えに よってタイムシグナルを放送しています。放送局ごとに独自の コード方式を使っており、その概要は NTP ウェブサイトに掲載 されています。 http://www.eecis.udel.edu/~mills/ntp/index.htm (このページの 最後のほうです)。ドイツの DCF77 では 77.5kHz、イギリスの MSF (ここは 所在地にちなんで "Rugby" とも呼ばれています) とコロラドの WWVB は どちらも 60 kHz で放送されています。

WWVB の受信感度は一定していませんが、放送出力を段階的に上げようという計画が あります。その進捗状況については NIST のウェブサイトをご覧ください http://www.boulder.nist.gov/timefreq/wwvstatus.html 。

シリアルポートに接続できる安価なレシーバがヨーロッパで入手可能だそうです。 `ntpd` にはいくつかの MSF レシーバ用のドライバが含まれて います。

合衆国の多くの会社が WWVB レシーバを組み込んだ比較的安価な時計を 販売しています (これには壁掛け用の時計もいくつか含まれています)。 しかし、著者の知る限り、コンピュータに接続できるのは 2 機種しか ありません。

Ultralink Model 320 という時計は (1999年6月時点で) 120 ドル程度ですが、 これはシリアルインターフェイスと ASCII 文字によるコマンド セットが使えるようになっています。それゆえ、プログラムを作るのは それほど難しくないはずです。これはシリアルポートから 1 mA の電源を 取ります。アンテナはコンピュータから 100 フィートまで離すことができ、 シグナルが得られない場合に備えて組み込みの内蔵クロックで時間を測定し 続けることができます。Ultralink ではベアボーン版も 80 ドル程度で 販売しています。これは "BASIC Stamp" シリーズのマイクロコントローラで 動くように設計されています。詳しくは次のウェブページをご覧ください。 http://www.ulio.com/timepr.html.

Arcron Technology は、シリアルポートをオプション装備した卓上時計を約 80 ドル で販売しています。これには Windows 用のソフトウェアも含まれています。 詳しくは次のウェブページをご覧ください。 http://www.arctime.com.

## 日本語訳について

誤訳・誤字・脱字については、<JF@linux.or.jp> までお願いします。

- 翻訳：
- 吉川雅英 <kikkawa@m.u-tokyo.ac.jp>
- (1997/01)
- 更新：
- 千旦裕司 <ysenda@pop01.odn.ne.jp>
- (2001/10/06)
- 校正：
- 高城正平 <takavoid@palette.plala.or.jp>
- 小林雅典 <zap03216@nifty.ne.jp>