この図は、横軸に経過時間(単位は 1時間 = 3600秒)、縦軸は、基準時刻との ずれを秒でプロットした物です。縦軸の offset の値が正の値を取る時、 基準時刻に対してシステムクロックが遅れている状態を意味します。 基準時刻は、LAN 内に置かれた、外部のntpサーバとntpdを使用して同期 しているマシンを利用しています。時刻の比較は clockadj-ntp コマンド を使用しています。0 hour の時刻で、clockadj コマンドを手動で実行し、 その後は、cron で、2時間に一度 clockadj コマンドを実行しています。 赤の↑は、clockadj コマンドを実行した時刻を示します。
最初の1時間は、カーネルの初期値のパラメターで、動作していますので、
どんどんシステムクロックがずれて行くのが分かると思います。このグラフの
傾きを測定すれば、周波数のずれは 70ppm 程度。一日に 6秒程度時刻が
ずれる事が分かります。PC/AT互換機としては標準的な量だと思います。
約1時間後の clockadj コマンドの実行で、カーネルのシステムクロックに
関するパラメータが調整されましたので、単位時間あたりのシステムクロック
のずれは小さくなり、5hour 以降は随分調子良く動作している事がおわかり
いただけると思います。
この図は、さらに長時間運用して測定した結果です。縦軸のスケールが
異なっているので注意して下さい。
ある程度周波数の調整が出来ている 11hour 以降でも、例えば、13 hour
近辺、25hour 近辺が極端にずれているのが分かると思いますが、実は
これは、基準にしている、LAN内のntpサーバの方がずれているのです。
貧弱な一般家庭用の回線、ネットワーク機器で、ntp を標準の設定で使用している
場合良く有る事なのです。途中から、外部の比較的信用できる ntp サーバ
として、ntp3.jst.mfeed.ad.jp と時刻比較した結果を緑のグラフで重ねて
プロットしています。参考にして下さい。
40hour 以降、 一日一回の時刻合わせに変更しましたが、それでも、0.02 秒
以内で、時刻があっている状態が維持できている事が分かるでしょう。
このテストした環境では、ADSL 回線でインターネット接続し、
ntp3.jst.mfeed.ad.jp から時刻を取得する際のパケットの往復に要する時間は、
0.06 秒程度要します。ntp サーバから時刻を取得する時点で、0.03秒弱の誤差が
見込まれる事を考えると、十分な性能と言えます。
所で、外部の ntp サーバに問い合わせている緑のグラフに、時々極端に大きな
offset を示す物がある事が気になると思います。特に 50hour, 70hour, 95hour
周辺はひどい物です。ここは、何が起こっているかというと、別のマシンで、
webのアクセス、ファイルのダウンロード等で、インターネット接続用の回線
の帯域をほとんど食い潰していました。ntpd で時刻合わせを行っているマシンは、
サーバへの問い合わせ時にこのような状態ですと、システムクロックが極端に
ずれる事があります。貧弱なネットワーク接続環境では、clockadj の不定基に
実行して良いと言う特性を利用して、回線の空いている時だけ、時刻比較を
行うように工夫すれば、ntpd より良い結果が得られるはずです。
このページに関する、ご意見、感想、苦情はこちらまで 松本 徳真 / matsu@netfort.gr.jp