Linux のシステム時計の時刻あわせ

2004年 7月 3日

松本徳真 < matsu@netfort.gr.jp >

このファイルは、もともとは LMSでの資料として作成した物で、 単独では、いまいち役に立たないので、少し文章を追加してみました。 追加した説明はこの色です。

概要

常時接続に限らず、ネットワークに接続されたコンピュータが勝手な時を 刻んでいたのでは、色々な問題が発生します。
本セミナーでは、Linux のシステム時計を個人ユーザーが可能な範囲でま ともにする事を考えます。

1) UNIX time, 協定世界時について、glibc での実装に付いて簡単に解説。
2) ntp 等有名な、時刻合わせ、時刻比較プログラムに付いて簡単な紹介。
3) 現在企画中の簡易時刻修正プログラムの紹介。

はじめに

協定世界時(UTC)について

協定世界時, 閏秒等の単語は聞いた事があると思いますが、これらが 何物か把握している人は少ないようです。コンピュータのシステム時計 に付いて考える前に協定世界時に付いて、簡単に解説してみたいと思います。

協定世界時で 06:00:00 頃と言えば日本ではお昼過ぎです。日常生活の便利の ためには、12:00:00 が、お昼であって欲しいものです。そこで、世界各地で 地方時と言うものが運用されています。東西に長い国では、複数の地方時が ある場合もあります。日本では、日本標準時(JST)が使用されています。 日本標準時は協定世界時に対してちょうど 9時間進んでいます。協定世界時で 2004年6月10日 0時0分0秒は、日本標準時では 2004年6月10日 9時0分0秒に なります。協定世界時と地方時の変換は、何時間進んでいるか遅れているか がわかれば機械的に簡単に計算できます（但し、夏時間が存在する、非文明国は 除く）。

ここの説明で、地方時と言う単語を間違って書いていますが、標準時 としておけば良かったかな。 本来の地方時は、経度が異なれば異なります。東京の 地方時と大阪の地方時は別物なのです。ただ、密接に繋がりあった地域内 で、時刻系が異なるのは不便です。そこで、日本国内では、東経135度に おける地方時を標準時として使用する事が法律で決められています。これが、 日本標準時です(聞いた話では、法律の条文中には日本標準時という単語 はなく、中央標準時となっているそうな)。
世界各国で標準時があり、それらの多くは、 UTC に対して整数時間の オフセット(ずれ)があるように 0, 15, 30, 45, ... 度のように15度の 倍数の経度における地方時を標準時として採用しています。もちろん 例外はあって、例えば America/St_Johns では、-3.5時間となっています。
UNIX で local time という単語が出て来ますが、これは、地方時では なく、各地方での標準時程度にとらえて下さい。

真太陽時

原始的な時計の一つに日時計があります。地面に棒を立てて、その影の位置で 時刻を知る事が出来ると言う簡単な物です。 ＜余談＞上の写真は、第二神明道路の明石SA で撮影した物です。この日時計は、多少近代的です。棒が斜めに立っていますが、 実は、この棒の傾きは、設置場所の緯度と等しく、棒の先端は真北を向いています。 つまり、この棒は、地球の自転軸と並行になるよう設置されているのです。＜/余談＞
このように、日時計で計る時刻は、地球表面から見た見掛け上の太陽の動きを、 直接的に表現する物で、日出、日没に同期して生活する人間にとっては、 非常に便利な時刻系と言えます。

恒星時, 平均太陽時

恒星時	恒星の観測から得られる。ある恒星が子午線を通過してから、 次に子午線を通過するまでの時間を一日とする。地球の自転をを 直接時刻に反映する。
真太陽時	地球表面から見た太陽の動きを基準にした時刻系。地球の軌道が楕円形である、 地軸が約23.4度傾いている等の事情で、季節によって一日の長さが異なる。
平均 太陽時	太陽時の季節変動分を平均化したもの。恒星時から計算で得ることができる。

±１時間程度の精度で良ければ、日時計は優れた時計です。この時刻系は、 地球の自転と、太陽のまわりを回る公転の組合せになります。そこで、 地球の自転軸は、公転面と垂直でない、地球の公転軌道は、楕円形で、 太陽に近い時は速く、遠い時は遅く運動すると言う影響で、季節によって、 一日の長さが異なる(昼の長さが異なるという話とは別の問題です)という 事になります。
日時計は、夜間や、曇の日は使用できません。その間は、何らかの時計に よって補間する訳ですが、一日の長さ(ひいては一秒の長さ)が変動する 時刻を表現するのは大変な話です。
そこで、季節変動分を平均化して作られたのが、平均太陽時です。 平均太陽時は、恒星の地球表面から観測したデータを元に、作成します。 恒星は、ほぼ無限遠のかなたにあるので、これは、地球の自転を直接的に 測定する事を意味します(実際には、無限遠のかなたにある訳ではなく、 視差がありますし、地球の公転による光行差とか恒星自身の固有運動の影響 とかありますが、これらは観測データの処理時に取り除きます)。
観測で得られた恒星時に公転による影響を計算で加えれば、平均太陽時が 得られます。

国際原子時(TAI)

協定世界時(UTC)

太陽時を基本とする世界時(UT)は、人間の日常生活に便利な時刻系であるが、 世界時がどんどん精密化されて行くと、地球の自転の不規則な運動に、 悩まされてきました。そこで、1972年から開始された現行の協定世界時(UTC)は、 国際原子時(TAI)を基準とすることになりました。協定世界時(UTC)は、 国際原子時(TAI)と同期し、世界時(UT1)からのずれが大きくなると、 閏秒(leap second)の挿入削除により調整されます。

TAI, UT1, UTC, leapsecond

国際原子時(TAI), 協定世界時(UTC), 世界時(UT1) がどのように 時を刻んで切るか模式的に示したのが以下の図です。

UNIX での実装

time_t time( time_t *time);
int gettimeofday( struct timeval *tv, struct timezone *tz );
等のシステムコールで、ある起点(1970/01/01 00:00:00 GMT) からの 経過時間を秒、またはマイクロ秒単位で得ることができる。
localtime(), localtime_r(),
gmtime(), gmtime_r()
等の libc に含まれる関数を使って、年、月、日、時、分、秒に 変換することができる。

古代の UNIX では、

unix time と呼ばれる time() の戻り値を、 年、月、日、時、分、秒に変換する際、1日を 86400( = 24時間*60分*60秒)秒 と決め打ちしていたが、かといって、TAI でも、UT1, UT2 とも 言えない不思議な時刻システムであった。
昔は、正確な時刻を取得する安価な手段がなかったので、そんなに 気にすることもなかったということか。
ただ、現在では、高速なネットワークで多くのコンピュータが接続される 中で、時刻同期の重要性は高まっているが、あいまいな基準では困るよね？

glibc, FreeBSD では、

glibc 2.1 以降では、従来の unix time 的な使用法ができる一方、 設定により、UTC に対応することもできる。 FreeBSDの libc でも、かなり早い時期から対応している。 他のUNIXシステムはわかりません。必要な人は各自で調べてね。

UTC対応の考え方

time() 関数の戻り値を、1970/1/1 00:00:10 TAI からの 経過秒数と定義する。
あるいは、1972/1/1 00:00:00 UTC の値を 63072000( =2*365*24*60*60 ) と 定義する。
time() 関数の戻り値から、年月日時分秒に変換するには、 閏秒(leapsecond)実施 のデータが必要。タイムゾーンが Asia/Tokyo に設定されている場合、
/usr/share/zoneinfo/Asia/Tokyo
に閏秒実施データが含まれていれば、UTC 対応のシステムとなり、含まれていな ければ、従来同様のシステムになる。

UTC対応システムの問題点

不定期に実施される閏秒の実施が決まれば、新しい閏秒実施データを取得し、
/usr/share/zoneinfo
以下を再構築する必要がある。
入手先
ftp://elsie.nci.nih.gov/pub/
自動化するのはそう難しくないので大した問題ではない。

UTC に対応していないアプリケーションが結構ありそう。

UTC 未対応アプリケーション例

ちょっと休憩

なにか質問ありますか？

時刻合わせの実際

時刻合わせの要素

時刻	時刻をあわせる。
周波数	時計のすすみ具合を調整する。

毎日時報を聞きながら腕時計をあわせる
→ ”時刻”をあわせる。

いつも遅れがちな時計を、時計屋さんで直してもらった
→ ”周波数”をあわせる

基準時刻の取得方法

GPS
長波JJY
テレフォンJJY
ネットワーク経由

ネットワーク経由の遅延対策

NTP プロトコルなどでは、比較的遅延の大きいネットワーク回線を利用して、 高精度の時刻比較が出来るよう、上記図のような方法を使用しています。
T0 .. クライアントが問い合わせのパケットを送出した時刻。
T1 .. サーバが問い合わせのパケットを受け取った時刻。
T2 .. サーバが返答のパケットを送出した時刻。
T3 .. クライアントが返答のパケットを受け取った時刻
を測定します。ここで、T0, T3 は、狂っているかも知れないクライアントの 時計で測定。T1,T2 は、正しいと考えられるサーバ側の時計で計測 しています。これを上記図の式の様に計算すると、クライアントの時計が どの程度ずれているかを知る事が出来ます。
ここでは、前提として、
1. 上り、下りのパケットは、同じ遅延時間(delay)を要する。
2. クライアントの時計のズレ量(offset)は、パケットが往復する間に 大きく変化しない。

現在一般家庭に普及している ADSL のように、上り下りの帯域が非対称な 回線では、1. の前提を期待するのは無理ですね。ADSL回線経由で、 ntpd を利用して時計を合わせた場合、見掛けの offset で 0.001 秒以内 程度は十分いけると思いますが、遅延(delay) が 50 m sec あるなら、 0.03 秒以内程度には合ってるかなぁ〜程度に考えておくべきでしょう。

ネットワーク経由の基準時刻取得プロトコル

ntp 123/udp	ネットワーク遅延対策あり サーバ： ntpd クライアント: ntpd, ntpdate, clockspeed, その他いっぱい
daytime 13/udp,tcp time 37/udp,tcp	ネットワーク遅延対策なし サーバ： inetd 内蔵 クライアント: netdate
ICMP TIMESTAMP	ネットワーク遅延対策あり サーバ： TCP/IP プロトコルスタック クライアント: clockdiff

上記表のようにネットワーク経由で、時刻比較を行うプロトコルは たくさんあります。通常の公開サーバでは、ntp プロトコルを使用 しています。ICMP TIMESTAMP については、TCP/IP の実装方法にも よりますが、カーネルの TCP/IP プロトコルスタック自体がその 機能を持っていますので、ntpd の様な daemon を意識して起動しなくても ネットワークに接続するだけで機能してしまいます( iptables 等で、 切る事は当然可能) 。ping で反応を返すようなマシンは、かなりの 確率でこの機能が有効です。とはいえ、マシンの管理者が、意識して 公開しているので無い以上勝手に使用して良いとは思えません。 実験してみたい人は、自分の管理するマシンか、管理者に了解を とってお試し下さい。

裏技その1

#!/bin/sh
host=$1
datestr=`wget -S --spider $host 2>&1\
|grep " Date: "` || exit
echo "${datestr##* Date: }"

裏技その2

#!/bin/sh
tmstr=`wget -q -O - \
http://www2.crl.go.jp/cgi-bin/JST.cgi \
|grep Standard`
tmstr=${tmstr#*\"}
tmstr=${tmstr%\"*}
echo $tmstr

裏技は使うな！！

公開 NTP サーバ

ntpd

clockspeed

時刻と、周波数の調整を行う。
ntpd がソフトウェア PLL によって、適宜周波数を調整するのに対して、 長時間の時刻ずれの測定により、周波数を決定する。
始めから UTC に対応した設計がなされている。
頻繁に基準時刻を取得できない環境で有利になる。
t = p * TSC +offset
で、p と offset を決定し、適宜システム時刻に反映する。
settimeofday(), ではなく、adjtime() を使用しているので、 時刻が逆戻りしたりする事はない。
Pentium および 互換 CPU の持つ TSC レジスタに依存。

現在企画(実験)中

おしまい

質問をどうぞ。